Una herramienta para la creación de interfaces multiplataforma con UIML

Transcripción

1 Una herramienta para la creación de interfaces multiplataforma con UIML Francis Casado DMR Consulting Edificio Prima Barcelona Avda. Diagonal, 605, 5ª Barcelona Toni Navarrete Departament de Tecnologia Universitat Pompeu Fabra Pg. Circumval lació, Barcelona toni.navarrete@upf.edu Sergio Sayago Departament de Tecnologia Universitat Pompeu Fabra Pg. Circumval lació, Barcelona sergio.sayago@upf.edu Josep Blat Departament de Tecnologia Universitat Pompeu Fabra Pg. Circumval lació, Barcelona josep.blat@upf.edu Resumen El presente artículo describe una herramienta para la creación de interfaces de usuario multiplataforma utilizando el lenguaje UIML. Su versión actual permite crear y visualizar interfaces para las plataformas Java estándar, J2ME en Palm y HTML. Se describe el proceso de diseño incremental centrado en el usuario basado en prototipos que se ha seguido para definir los requerimientos de la herramienta y se detallan algunos aspectos de la implementación referentes a la librería Java para el manejo de UIML y la generación y ejecución de código fuente en las plataformas específicas. 1. Introducción Diseñar interfaces de usuario multiplataforma está adquiriendo cada vez mayor importancia. Con una creciente diversidad de dispositivos, plataformas y tecnologías, los diseñadores se ven obligados muchas veces a crear versiones alternativas de las interfaces. Actualmente, este proceso es muy costoso. Muy pocas herramientas IDE (Interface Development Environment) facilitan a la generación de interfaces multiplataforma. Una de las soluciones a este problema es mediante representaciones abstractas de las interfaces, que permiten especificar las interfaces independientemente de dispositivo, tecnología y plataforma. Además, también permiten a los diseñadores centrarse más en el modelo del diseño que en los detalles de visualización propios de cada plataforma. Aunque se han propuesto varios lenguajes abstractos para la representación de interfaces (entre ellos, UIML), estos esfuerzos no han ido ligados a herramientas IDE que les den soporte. En este artículo presentamos el diseño e implementación de una herramienta IDE para la creación de interfaces abstractas y multiplataforma con UIML. Remarquemos que aquí no entramos en la importante cuestión si la descripción abstracta de las interfaces debe contener aspectos específicos de los dispositivos, ya que las interfaces PDA tienen que ser diferentes de las de un ordenador, por las características del dispositivos y por las expectativas y patrón de uso. Este tema lo hemos explorado de forma inicial en [5]. Para el diseño del IDE realizamos un análisis comparativo de diferentes lenguajes abstractos, y también seguimos algunos aspectos de un modelo clásico de diseño centrado en el usuario. Para su implementación se ha desarrollado una librería de código abierto en Java para generar y cargar ficheros XML que satisfacen la especificación UIML, así como un procesador de lenguaje XML para generar interfaces Java estándar, J2ME y HTML a partir de un fichero UIML. La herramienta permite además las correspondientes visualizaciones en función de las plataformas seleccionadas. Los resultados iniciales indican que este tipo de aplicaciones pueden ser útiles tanto a diseñadores como a desarrolladores. Por un lado, la herramienta permite a los diseñadores abstraer todos aquellos detalles propios de la visualización de la interfaz en una plataforma concreta para concentrarse más en el modelo del diseño (disposición de los elementos, estructura de navegación ), al tiempo que una

2 visualización temprana de los diferentes resultados. Por otro lado, el hecho de generar el código fuente de las interfaces ahorra tiempo de desarrollo a los programadores. Conviene aclarar que aunque UIML no soporta user tasks, esenciales para hacer un diseño centrado en el usuario, en nuestro trabajo de diseño de la herramienta sí se ha seguido esta metodología; vale también la pena añadir que cualquier diseñador, aunque utilice nuestra herramienta tendrá, como es natural, que seguir convenientemente dicha metodología (o bien diseño participativo, o centrado en el uso,...) El artículo está organizado como sigue. En la sección tercera se describe el proceso del diseño iterativo centrado en el usuario, y se detallan los requerimientos que debe cumplir nuestra herramienta. En la sección cuarta se desarrollan los aspectos de la implementación más relevantes como son la librería para el manejo de documentos UIML y la generación y ejecución del código fuente a partir de tales documentos. Finalmente, se enumeran los principales resultados de nuestro trabajo así como las perspectivas futuras. Para una descripción detallada de la herramienta, así como de la fase de diseño y del análisis de lenguajes de representación de interfaces, puede consultarse [1]. En la siguiente sección se presenta una breve revisión de los lenguajes declarativos para la representación de interfaces y se justifica la elección de UIML. 2. Lenguajes para la representación de interfaces de usuario En este apartado se revisan, en primer lugar, varios lenguajes ligados a frameworks de construcción de interfaces de usuario. A continuación se describen brevemente otros lenguajes como XForms, AUIML, AAIML, UsiXML y XIML. La sección finaliza con el análisis de UIML y las causas que han hecho que finalmente sea el que hemos utilizado en nuestra herramienta. Puede encontrarse también una revisión comparada de algunos de estos lenguajes en [2] y [7] Lenguajes en el marco de frameworks de construcción de interfaces Los lenguajes que se utilizan en diferentes frameworks para el desarrollo de interfaces de usuario, generalmente multiplataforma, que se describen a continuación son QT UI, Glade XML, XAML y XUL. QT UI QT [8] permite el desarrollo de interfaces multiplataforma y tiene soporte para todos los componentes gráficos habituales, con la particularidad de que los programadores pueden extenderlos o modificarlos. Los componentes gráficos de QT emulan exactamente la apariencia de las plataformas de destino, según los estilos de cada una. Esta técnica permite a los programadores derivar sus propios estilos, lo que diferencia a QT de otros frameworks. Vale la pena mencionar también que la relativa facilidad de aprendizaje y uso de QT hace que numerosos programadores lo utilicen incluso en desarrollos para una única plataforma. QT Designer es una herramienta para el diseño de interfaces. Utiliza un documento XML para describir y almacenar la interfaz. Este documento sigue un formato propio denominado UI (User Interface), cuyo esquema establece una serie de elementos XML para los propios componentes, propiedades, funciones, layout, entre otras características de la interfaz. Glade XML Glade [9] es un generador de interfaces para GTK+ y GNOME, bajo licencia GNU GPL. Glade XML es el formato XML en el cual se almacenan las interfaces generadas por Glade. Además, la librería libglade permite la carga de los fichero de interfaz de forma dinámica por parte de las aplicaciones. Glade XML puede usarse desde numerosos lenguajes de programación. XAML XAML (Extensible Application Markup Language) [3] es un lenguaje basado en XML para la descripción de interfaces de usuario para aplicaciones Windows. XAML se está desarrollando para la próxima versión de Microsoft Windows; cuyo subsistema de

3 presentación será conocido con el nombre clave de Avalon. XAML consta de una serie de elementos XML para representar los principales componentes gráficos, así como el layout, paneles y manejadores de eventos. También existen elementos para el manejo de gráficos vectoriales. El objetivo es que las aplicaciones de Avalon utilicen XAML para la definición de la interfaz, mientras que se utiliza otro lenguaje para escribir el código. Éste código puede ir incrustado en un documento XAML, o bien mantenerse en un fichero separado. XUL XML User Interface Language (XUL) [10] es un lenguaje basado en XML desarrollado por Mozilla para la definición de interfaces de usuario multiplataforma, principalmente orientadas a aplicaciones de red. Mientras HTML describe el contenido de una página, XUL describiría la interfaz, incluyendo la propia ventana del navegador. Así, el lenguaje consta de una serie de elementos XML para los principales componentes gráficos como ventanas, barras de estado, etiquetas, botones, enlaces, etc. XUL puede ser utilizado en cualquier plataforma en la que exista Mozilla. De hecho, la interfaz de usuario de todas las aplicaciones de Mozilla (navegador, lector de correo,...) están escritas en XUL UsiXML El USer Interface extensible Markup Language (UsiXML) [11] permite la descripción de interfaces de usuario multimodales, con diferentes formas de interacción, en diferentes plataformas y dispositivos. UsiXML describe a un alto nivel de abstracción los elementos de una interfaz, pero no sólo los widgets o componentes gráficos, sino también los modos de interacción. Diferentes renderers permiten su ejecución en diferentes dispositivos y plataformas XForms XForms [12] es una especificación del W3C enfocada a formularios para una gran variedad de dispositivos, tanto electrónicos como incluso en papel. Xforms propone un modelo de interfaz de usuario que sea rica en contenido, de manera que sea válida tanto para las aplicaciones comerciales como para las pequeñas aplicaciones de usuario personal e individual. Permite una completa separación de la lógica de presentación y de la lógica de datos, así como la internacionalización y la posibilidad de tener múltiples formularios en una página, de la misma manera que múltiples páginas a través de un formulario. Hay que destacar también que se puede integrar perfectamente con otros entornos XML y trabajar con ellos conjuntamente AUIML El Abstract User Interface Markup Language (AUIML) [13], desarrollado por IBM, es un lenguaje XML para la descripción de interfaces de usuario. El lenguaje permite representar diferentes componentes gráficos, sus propiedades, así como su distribución en paneles y el layout. Diferentes renderers convierten el documento AUIML a una interfaz para cada plataforma. IBM ha desarrollado también el AUIML Toolkit, que incorpora una herramienta de construcción de una interfaz de usuario (AUIML Visual Builder) y que genera un documento AUIML. El toolkit también tiene renderers para generar la interfaz en Java Swing o en HTML. También puede crear manejadores de eventos o Java Beans para el manejo de datos. De hecho el AUIML Visual Builder es un plugin de Eclipse, con lo que se unifica la generación de la interfaz abstracta y del código AAIML El InterNational Committee for Information Technology Standards (INCITS) está desarrollando un estándar para un Universal Remote Console (URC) en el marco de lo que denominan Alternate User Interface Access. La URC ofrecería una interfaz a un gran abanico de dispositivos electrónicos como puedan ser sistemas de seguridad, termostatos, etc. Un elemento central en la definición del URC es el lenguaje Alternate Abstract Interface Markup Language (AAIML) [6]. AAIML permite definir de forma abstracta una interfaz de

4 usuario. Cada URC ha de ser capaz de renderizar un documento AAIML según sus propias peculiaridades; AAIML está basado en un modelo de eventos para facilitar la interacción entre la URC y el dispositivo. El lenguaje define una serie de elementos abstractos para identificar las operaciones de entrada y salida, y no directamente los widgets como ocurre en otros lenguajes. Cada URC traduce un elemento abstracto a un elemento específico de la plataforma. Por ejemplo, el elemento abstracto string-selection se podría convertir en un radio button en una interfaz visual, o en una opción mediante voz en otra interfaz basada en el habla XIML El extensible Interface Markup Language (XIML) [13] tiene como objetivo dar soporte a todo el ciclo de vida del diseño de una interfaz gráfica de usuario. Esta afirmación incluye las fases de diseño, desarrollo, operaciones sobre la interfaz, manejo de la misma, organización de los diversos componentes y la evaluación de la misma [4]. XIML divide los componentes que pueden ser utilizados para la generación de interfaces en diversos grupos, separados según su especialización. Hay tipos especializados como Tareas (business processes), Dominios (define una jerarquía de componentes dentro de un dominio), Usuario (define una jerarquía de usuarios finales), Presentación y Diálogos (definen acciones que se relacionan directamente con la interfaz). Todos estos componentes son mapeados a elementos que no son más que representaciones concretas de los widgets o componentes gráficos que se utilizarán para la representación de la interfaz Nuestra elección: UIML UIML (User Interface Markup Language) [15] es un lenguaje XML para definir de forma abstracta interfaces de usuario de manera independiente de la plataforma. Básicamente, UIML describe una interfaz en tres niveles: presentación, contenido y lógica. La presentación se refiere a la apariencia de la interfaz; el contenido se refiere a los componentes de la interfaz; la lógica se refiere a la interacción usuario interfaz (eventos del ratón, teclado ). En UIML, una interfaz de usuario es una jerarquía de elementos XML. Cada uno de los componentes de una interfaz (botones, cajas de texto, etiquetas ) son una entidad XML. Estas entidades son elementos Part. Cada uno de tiene asociado un elemento Content, que puede ser texto, imagen, etc. UIML utiliza un vocabulario abstracto. Los elementos XML de UIML son genéricos; por ejemplo, no aparecen elementos XML con la terminología menú, ventana, etc. UIML permite la descripción de interfaces de diferentes pelajes. Con UIML se pueden describir tanto interfaces web como de escritorio. Un ejemplo de la variedad de interfaces son las que nuestro IDE permite crear. En secciones anteriores hemos resumido muchos lenguajes XML para la representación de interfaces. Después de todo un análisis de estos lenguajes (véase [2]), algunos de los lenguajes similares a UIML parecen estar en fase tentativas de definición, como AUIML; y otros están fuera del ámbito de nuestro IDE, como AAIML para el acceso universal a la información. En este artículo pensamos que vale la pena resumir la comparación de UIML con XIML y XForms. Por un lado, XIML parece dar mucho más soporte que UIML en fases iniciales de diseño de la interfaz. Sin embargo, UIML puede ser utilizado en estas fases iniciales de diseño, como mostramos en el IDE diseñado. Pensamos que, como UIML es metalenguaje, también se puede aplicar a fases más tardías del diseño de la interfaz. En comparación con XFroms, UIML puede ser utilizado para realizar descripciones de interfaces de usuario que pueden ser descritas utilizando XForms. Además, UIML puede describir interfaces que contengan más elementos de los que XForms es capaz de representar. 3. Diseño incremental centrado en el usuario A pesar de que, como se ha discutido en el la sección 2, existen varios lenguajes declarativos para la representación de interfaces de usuario,

5 no se puede hablar de ninguna herramienta IDE que basada en ellos dé realmente soporte para la creación de interfaces abstractas multiplataforma. Sí existen, no obstante, herramientas de desarrollo que permiten el desarrollo de aplicaciones para diferentes plataformas y en concreto de sus interfaces gráficas. NetBeans, CodeWarrior o Microsoft Visual Studio son ejemplos, que bien directamente o bien extendidos con ciertos paquetes, permiten desarrollar aplicaciones tanto para escritorio, como para web como para dispositivos PDA. No obstante, no resuelven el problema de portabilidad de la interfaz, en el sentido de que no están enfocadas a poder reutilizar la interfaz de una aplicación en una plataforma (por ejemplo para PDA) en otra (por ejemplo web). Evidentemente tampoco cumplen este objetivo las herramientas orientadas al desarrollo de páginas web, como Macromedia Dreamweaver o similares. A pesar de estas limitaciones, lo que sí se ha podido observar en la gran mayoría de los casos analizados es que siguen un paradigma más o menos similar. Éste se basa en la existencia de normalmente dos vistas. La primera, a la que llamaremos de diseño, permite visualizar la interfaz y modificarla gráficamente. Ésta vista incluye normalmente una serie de mecanismos para visualizar y editar ciertas propiedades de los objetos de interfaz que se van utilizando. La otra vista, a la que llamaremos de código, permite visualizar y editar el código asociado, lo que generalmente permite un mayor control sobre ciertos parámetros concretos. Ésta es la principal conclusión que se extrajo de una primera etapa (análisis competitivo) de diseño centrado en el usuario. Con los resultados de este análisis, se determinó que la herramienta IDE habría de tener dos vistas: la vista de diseño y la vista de código. Por una parte la vista de diseño de la interfaz para asegurar que el usuario sepa lo que está colocando en la interfaz de usuario y, por otra parte, la vista de código, para asegurarse de lo que ha colocado y que se ha generado su código fuente asociado de manera correcta. Y además, serán necesarios unos mecanismos de comunicación entre vistas para que un cambio en una afecte a la otra. Después del anterior análisis competitivo de herramientas, se recogieron algunos requerimientos de usuario. Para esto, utilizamos entrevistas y reuniones informales del estilo lluvia de ideas (brainstorming). A continuación, durante la fase de diseño, se siguió un proceso de diseño participativo en el que se integró a un equipo de desarrolladores y diseñadores como potenciales usuarios de la herramienta. En esta etapa los usuarios utilizaron las primeras versiones del prototipo, con el objetivo de que aportaran ideas e identificaran problemas. Los resultados de esta fase fueron un conjunto de sugerencias y problemas de diseño. Los principales problemas identificados fueron dos: (i) el flujo de trabajo y (ii) la necesidad de mejorar la visualización de los elementos gráficos en la interfaz. Para solucionar estos problemas varias soluciones fueron implementadas. Posteriormente, para comprobar que satisfacían los requerimientos de los usuarios, realizamos una serie de evaluaciones informales. Las acciones de evaluación consistieron en que los usuarios volvieran a utilizar la aplicación y nos dijeran si las soluciones habían mejorado la anterior versión, que realizarán tareas del estilo: crear un formulario para visualizarlo en HTML, etc. Después de estas evaluaciones, el prototipo final permite la creación de interfaces basadas en formularios en las que se puedan utilizar los siguientes componentes: - etiquetas - botones - campos de texto - áreas de texto (de varias líneas) - botones de selección - listas de selección - marcos o paneles que agrupan componentes Hay que aclarar que no todos los componentes tienen sentido en todas las plataformas posibles. Conviene comentar también que el sistema es completamente abierto a la introducción de nuevos tipos. Las plataformas que se han elegido para probar los prototipos de herramientas son:

6 - web: HTML - aplicaciones de escritorio: Java estándar (J2SE) - dispositivos de pequeño tamaño (PDA): Java Micro Edition (J2ME) A raíz de este proceso iterativo e incremental basado en prototipos se fueron estableciendo los requerimientos finales de la herramienta, que aquí se comentan: 1) El usuario ha de poder añadir gráficamente un componente a la vista de diseño y desplazarlo al lugar que desee (drag-anddrop) 5) El usuario ha de poder gestionar con su herramienta diferentes documentos UIML 6) El usuario ha de poder tener un control del tamaño de pantalla del dispositivo. Esto es especialmente importante en el caso de PDA Es importante destacar que este control es muy importante para el diseño de interfaces PDA. Las interfaces PDA se suelen caracterizar por espacios reducidos de visualización, expectativas y patrones de uso, totalmente diferentes al PC de sobremesa. Por tanto, el diseño de interfaces abstractas debería tener en cuenta estos requerimientos. Estos aspectos los tratamos de manera inicial en [5] y, algunos de ellos, como la necesidad de tener control del tamaño de pantalla, fueron implementados en esta herramienta. Figura 1. Primer prototipo que permite añadir una etiqueta sobre el canvas 2) El usuario ha de poder visualizar y editar las propiedades del componente seleccionado 3) El usuario ha de poder visualizar un árbol en el que se muestren los componente existentes (y su tipo) Árbol de componentes Visualización y edición de propiedades Figura 2. Prototipo que incluye la edición de propiedades y el árbol de componentes 4) El usuario ha de poder ver el código UIML de la interfaz que está diseñando Figura 3. Versión final: edición de un formulario para PDA con limitación de tamaño 7) El usuario ha de poder ver la implementación de la interfaz en cualquiera de las plataformas. Esto se hace a partir del documento UIML de descripción de la interfaz y diferentes renderers para cada plataforma. En el apartado 4.2. se profundiza en este aspecto. 4. Implementación En primer lugar se presenta una librería que se ha desarrollado y que utiliza la herramienta para el manejo de documentos UIML. A continuación se describe el proceso de generación del código fuente para las plataformas seleccionadas. Se incluyen también algunos aspectos relacionados con la compilación y ejecución del código generado, en particular para plataformas J2ME.

7 4.1. juiml: una librería Java para el manejo de UIML Para crear una capa intermedia mediante la cual se abstraigan todas las operaciones de acceso a documentos UIML se ha desarrollado la librería juiml. JUIML ha sido desarrollada en Java, proporciona por tanto los mecanismos de lectura y escritura de documentos UIML, en concreto de la versión 3.0. De esta forma, se facilita el desarrollo de aplicaciones, como el caso concreto del IDE, que utilicen UIML, ya que los programadores no tendrán que trabajar con accesos directos a APIs de XML, sino a un conjunto de clases Java a un nivel más alto, relacionadas con la especificación UIML. La librería utiliza la API de JDOM para la parte relacionada con el manejo de estructuras XML, así como Xerces para llevar a cabo las tareas de validación. La parte central de la librería es un conjunto de clases que siguen una correspondencia directa con cada uno de los elementos de UIML, con lo cual el programador tiene un fuerte control sobre los elementos de la especificación. La librería permite tanto la carga de documentos XML como la generación de otros a partir de la nada o de otro previo cargado en la librería. Además se añaden servicios de parseo de XML y serialización. La serialización ésta basada en el patrón chain of responsability. La idea central de este patrón es que en una cadena o jerarquía de objetos, cada uno de ellos es el responsable de controlar sus propios comportamientos y sus propias operaciones, siguiendo una especie de cadena. Es decir, cuando se realiza la ejecución de un mecanismo de serialización, el primer objeto invoca al segundo, que se serializa, y hasta que no haya finalizado su serialización, no se realiza la serialización del padre. Además de la librería juiml se ha desarrollado una sencilla herramienta visual de validación de documentos UIML. La herramienta permite abrir un documento UIML y comprobar que su estructura se adecue al esquema XML de UIML, tanto en sus versiones 2.0 como Generación y ejecución de código fuente Una vez se ha generado el documento UIML que describe la interfaz, éste ha de ser traducido al lenguaje específico de la plataforma seleccionada. Para ello se ha utilizado XSLT. Así pues, hay un fichero de transformación XSLT para cada plataforma soportada. En el caso de Java estándar, hay que transformar cada tipo de componente UIML a un componente Swing. Por ejemplo un elemento del tipo botón, se genera un objeto de la clase JButton. A partir de las propiedades que figuran en el documento UIML se van también dando valores a los atributos de dicho objeto. Así mismo se le pueden asignar diferentes listeners para diferentes tipos de eventos. El formulario completo se corresponde con una clase que se crea dinámicamente y que extiende JPanel. Una vez generado el código fuente en Java, la herramienta permite compilarlo y ejecutarlo. En el caso de J2ME, se ha utilizado la librería de interfaz gráfica kawt en vez de la más limitada LCDUI, que es la que incorpora el propio J2ME. kawt permite trabajar con más tipos de componentes y situarlos con mayor libertad en la pantalla. Además presenta una mayor similitud con las interfaces de Java estándar, lo que en cierta medida facilita la transformación. Como particularidad, y debido a que se ha seguido el perfil MIPP de J2ME, el formulario completo se corresponde con un midlet, sobre el que se añaden los diferentes componentes y los manejadores de eventos. En este punto, vale la pena comentar que la herramienta permite la visualización de la interfaz en J2ME mediante un emulador, en concreto de Palm OS. Para ello la herramienta lleva a cabo de forma transparente todos los pasos necesarios para, una vez generado el código fuente, compilarlo, preverificarlo, empaquetarlo en un jar con su correspondiente fichero de manifiesto y enviarlo al emulador para la visualización. El caso de la transformación a HTML es el más sencillo. El documento UIML se convierte en un elemento Form de HTML, con sus correspondientes elementos correspondientes a los botones, listas y demás. Para la ejecución del código generado, en este caso la herramienta abre un navegador web.

8 detallada por parte de usuarios de la herramienta final, y se está trabajando en una nueva versión de la herramienta que soporte más aspectos de UIML: más componentes gráficos y elementos relacionados con la lógica de la interfaz. Referencias Figura 4. Ejemplo de visualización de formulario en HTML, Java y J2ME (en Palm) 5. Resultados y perspectivas futuras En general, los resultados iniciales indican que este tipo de aplicaciones pueden ser útiles tanto a diseñadores como a desarrolladores. Para los diseñadores, la abstracción permite concentrarse más en el modelo del diseño que en los aspectos de visualización impuestos por los actuales IDEs, y visualizar estos prototipos conceptuales muy rápidamente. Para los desarrolladores, la generación de código fuente de manera automática para distintas plataformas ahorra un considerable tiempo de desarrollo. Como perspectivas futuras, en primer lugar se está realizando una tarea de evaluación más [1] F. Casado: Programación de la adaptación de un portal web a dispositivos móviles. Proyecto Final de Carrera, Ingeniería en Informática, Universitat Pompeu Fabra, 2004 (director T. Navarrete). En [2] N. Hurtado, J..M. González, J. Torres: Revisión de Lenguajes Declarativos para la Descripción de Interfaces de Usuario Independientes del Dispositivo. Actas del V Congreso Internacional de Interacción Persona-Ordenador. Lleida, España, 2004 [3] C. Petzold: Create Real Apps Using New Code and Markup Model. En /Avalon/default.aspx [4] A. Puerta, J. Eisenstein: XIML: A Universal Language for User Interfaces. White Paper. pdf [5] S. Sayago, T. Navarrete, J. Blat: Técnicas de Ingeniería de Usabilidad y metodología de diseño conceptual en algunas aplicaciones informáticas. Actas del IV Congreso Internacional de Interacción Persona- Ordenador. Vigo, España, 2003 [6] G. Zimmermann, G. Gilman, A. Vanderheiden,. Universal: Remote Console Prototyping of an Emerging XML Based Alternate User Interface Access Standard. Actas del 11th Internacional World Wide Web Conference. Honolulu, EE. UU [7] XML Markup Languages for User Interface Definition. Cover Pages. En [8] [9] [10] [11] [12] [13] [14] [15]