Herramientas 3

112 Herramientas

Última modificación: 21/12/2001

Objetivos 3Introducción 41 Sistemas basados en manipulación directa42 Técnicas de diseño 53 Arquitecturas 74 Herramientas de diseño y construcción de

IU 95 Ejemplos de lenguajes de marcado en la

red 15Conclusiones 17Referencias 17Bibliografía 18

Objetivos Ofrecer una visión global de las herramientas para la creación de

interfaces de manipulación directa. Presentar las técnicas de diseño y las arquitecturas disponibles para las

interfaces gráficas de usuario. Analizar los entornos de desarrollo existentes para la construcción de

sistemas interactivos. Introducir los lenguajes de marcado como herramientas para el desarrollo

de sistemas web.

IntroducciónComo se ha visto en capítulos anteriores, en todo desarrollo de aplicaciones interactivas, el diseñador debe establecer los mecanismos de comunicación entre el sistema y el usuario. En particular, en las interfaces de manipulación directa, en las que se ofrece al usuario un conjunto de elementos gráficos con los que podrá interactuar, se debe definir cuáles son las operaciones que se van a poder llevar a cabo sobre estos elementos y cuáles son los efectos que se producen como consecuencia de esas acciones. Una vez que la interacción ya está diseñada, el programador debe encargarse de gestionar complejos objetos de información que representan, por un lado, a estos elementos gráficos y a sus comportamientos y, por otro, a los dispositivos de entrada y salida a través de los cuales los usuarios recibirán/emitirán información. Para realizar esta labor necesitan disponer de herramientas de desarrollo que les faciliten la implementación de sistemas interactivos [DIX98].Estas herramientas se caracterizan porque ayudan a minimizar el esfuerzo necesario para trasladar la semántica del diseño de la interfaz a la semántica que ofrece el entorno operativo con el que se está trabajando y se integran en el proceso de desarrollo de la interfaz [BAE95]. Además, estas herramientas facilitan la realización de modificaciones sobre el producto, haciendo posible el desarrollo de prototipos. De esta forma se puede integrar el proceso de evaluación en el ciclo de desarrollo, haciendo efectivo el diseño iterativo que proporcionará un producto más útil y utilizable.Este capítulo recoge algunas de las arquitecturas para el desarrollo de sistemas interactivos y algunas de las alternativas que se le ofrecen al programador a la hora de desarrollar sus aplicaciones. En concreto, se presentará cómo se desarrollan estas interfaces interactivas utilizando lenguajes de programación (v.g., el entorno abstracto de ventanas —AWT— de Java), asistentes de entornos de desarrollo ( v.g., VisualBasic), herramientas de autor (v.g., ToolBook) y, por último, se presentarán, algunas de las opciones disponibles para el desarrollo de entornos virtuales (v.g., VRML). A continuación y debido fundamentalmente a la importancia y popularidad que ha adquirido la web, se incluye una sección dedicada a explicar los fundamentos de los lenguajes de marcado como herramientas para la especificación de contenidos, que no de la interfaz de usuario.

1 Sistemas basados en manipulación directaTal como hemos descrito en el tema de los estilos de interacción, el término manipulación directa, acuñado por BEN SHNEIDERMAN en 1983, se refiere al hecho de que los usuarios puedan llevar a cabo las tareas y observar sus resultados de forma inmediata sirviéndose de la representación visual tanto de los objetos como de las acciones. Sin embargo, una de las principales desventajas de la manipulación directa es que su programación es compleja y normalmente requiere la utilización de elementos gráficos de cierta complejidad.El principal objetivo de las herramientas software utilizadas en el diseño y desarrollo de interfaces basadas en la manipulación directa consiste en facilitar la programación y el manejo de los elementos gráficos. Estas herramientas se pueden dividir en dos grandes grupos: aquellas que sirven para programar elementos gráficos y aquellas que parten de esos elementos gráficos para construir las interfaces. La separación en estos dos grupos es difícil de establecer, ya que normalmente las herramientas de programación disponen de librerías que se pueden considerar como componentes ya disponibles, y las herramientas basadas en componentes requieren algún tipo de programación para su adecuación a cada interfaz concreta.

Herramientas 5

En primer lugar se presentan técnicas de diseño de interfaces que se deberían seguir a la hora de dotar a un sistema interactivo de una interfaz gráfica de usuario. A continuación, y con el fin de situar cada uno de los tipos de herramientas dentro del sistema en el que se enmarcan, se presentan las arquitecturas sobre las que se desarrollan y explotan los sistemas de manipulación directa. Por último se presentan las herramientas disponibles divididas en herramientas de programación y herramientas basadas en componentes.

2 Técnicas de diseñoLa interfaz de usuario es un aspecto muy importante a tener en cuenta dentro del proceso de desarrollo de sistemas interactivos, llegando a suponer esta parte alrededor de la mitad del código final de la aplicación. Aunque se puede desarrollar una interfaz de usuario partiendo de cero, la solución más comúnmente usada, por razones de eficiencia y uniformidad, entre otras, es apoyarse en arquitecturas que incluyen gestores de ventanas y a veces también cajas de herramientas. Esto implica que la interfaz estará íntimamente relacionada con el sistema de gestión de ventanas, por lo que se hace aconsejable una separación entre la aplicación y su interfaz para conseguir los siguientes objetivos:

Portabilidad. Permitir que una misma aplicación pueda ser utilizada en diferentes sistemas.

Reusabilidad. La separación incrementa la reusabilidad de los componentes.

Múltiples interfaces. Flexibilidad para disponer de diferentes interfaces para la misma funcionalidad.

Personalización. Adecuar las características de la interfaz a las preferencias y necesidades del usuario sin tener que modificar la aplicación.

Siguiendo estos principios se describen a continuación tres posibles modelos de arquitectura para la construcción de interfaces de usuario: el modelo Seeheim, el Model–View–Controller, y el PAC.

Modelo SeeheimEl Modelo Seeheim se presentó en 1985 dentro una por aquel entonces nueva categoría de herramientas denominada UIMS (User Interface Management Systems). El modelo plantea la comunicación entre el usuario y la aplicación estructurada en tres niveles:1) El nivel de presentación. La parte estática y visible de la interfaz que se

comunica con el usuario y se construye sobre sistemas de ventanas y cajas de herramientas. Supondría el léxico de la interfaz.

2) El nivel de diálogo. La parte dinámica que maneja los eventos o mensajes que se producen como consecuencia de las acciones del usuario sobre la interfaz, y establece la comunicación entre el nivel de presentación y el nivel de aplicación, es decir, establece la relación entre los eventos y su correspondiente respuesta por parte del nivel de aplicación. Se podría equiparar a la sintaxis de la comunicación entre los otros dos niveles.

3) Interfaz de aplicación. La parte de la aplicación que el usuario controla a través de la interfaz y que es visible para éste último. Equivaldría a la semántica de la aplicación.

La división en capas facilita el tratamiento de cada una por separado y además promueve la reutilización y la portabilidad, con lo que se posibilita el desarrollo rápido de prototipos, tarea fundamental para un diseñador.

6 La interacción persona-ordenador

Model–View–Controller (MVC)Una de los inconvenientes que podríamos encontrar en el modelo Seeheim es que considera únicamente una arquitectura modular, pero no presta atención a la relación entre el modelo conceptual y el modelo mental del usuario. La interfaz de usuario debería ser capaz de representar los objetos de la aplicación de modo que el usuario comprenda la relación entre la representación y el mundo real. Los objetivos que se plantean son:

El usuario percibe y actúa sobre objetos. El usuario conoce los objetos por su comportamiento.

MVC es un modelo arquitectónico utilizado en el entorno de desarrollo de Smalltalk–80, y se puede utilizar para la construcción de aplicaciones interactivas. Todos los objetos de una aplicación (OO) se ajustan al modelo MVC.Los tres componentes de MVC corresponden a los tres componentes externos de la interfaz de usuario. Bajo un paradigma de objetos, los métodos externos encapsulan el estado del objeto. Esta representación explícita enfatiza que los componentes de la interfaz son objetos y no funciones o programas. Los componentes son los siguientes:

1) Modelo. El modelo refleja la estructura del modelo conceptual. El modelo es la información que manipula la aplicación y que supone la representación de los objetos reales pero de forma totalmente independiente de su representación visual.

2) Vista. Comparte la misma estructura y se encarga de la presentación sobre los dispositivos de salida (gráficos) del modelo de forma tangible, es decir, se encarga de su representación visual.

3) Controlador. Establece cómo los componentes interactuan con los eventos, es decir, cómo responden a éstos, de modo que la vista será la encargada de reflejar visualmente la respuesta a cada evento, pudiéndolo hacer de forma distinta para cada vista.

Un mismo modelo se puede asociar a diferentes triadas para obtener diferentes técnicas de presentación/interacción. Cada par V–C sólo se puede asociar a un único modelo.

Arquitectura multi–agente (PAC)Arquitectura propuesta por J. COUTAZ [DIX98] que se apoya en tres pilares básicos: presentación–abstracción–control.

Presentación: Gestiona las entradas/salidas Abstracción: Representa la semántica de la aplicación. Control: Gestiona la el diálogo y la correspondencia entre la aplicación y

presentación.Como se puede apreciar, es una arquitectura bastante similar a la MVC, aunque existen diferencias entre ellas. PAC agrupa la entrada/salida en la presentación, mientras que en MVC la vista se ocupa de la salida y el controlador de la entrada. Además, PAC introduce el control como mecanismo para mantener la consistencia entre la abstracción y la presentación, lo que en MVC no supone una tarea asignada de antemano. Por último, PAC no ha nacido vinculado a ningún entorno de programación, como le ocurre a MVC, aunque ambos lleven a una aproximación orientada a objetos.

Herramientas 7

3 ArquitecturasEn la actualidad, el entorno más común de manipulación directa sigue siendo la interfaz WIMP (Windows, Icons, Menus and Pointers) por lo que nos centraremos en los sistemas de ventanas. La arquitectura genérica de un sistema de ventanas se puede dividir en los siguientes niveles desde el punto de vista de las interfaces de usuario:

Sistema de ventanas – Gestor de ventanas. Juego de herramientas (Toolkit). Herramientas de alto nivel.

Un sistema de ventanas divide la pantalla en diferentes regiones normalmente rectangulares, denominadas ventanas, y se apoya en el gestor de ventanas. El sistema de ventanas supone la interfaz funcional, permitiendo a la aplicación escribir y dibujar en la pantalla y también recibir información del usuario. El gestor de ventanas permite al usuario final mover y redimensionar las ventanas, y es el responsable de presentar la barra de títulos, los límites y los iconos de las ventanas.Una de las características más importantes de un sistema de ventanas es su habilidad para dar una independencia al programador de los dispositivos de hardware. Los dispositivos de que dispone por el momento un ordenador para la manipulación directa son una pantalla, un teclado y un ratón. El programador tiene que interaccionar con un terminal abstracto que comprende un lenguaje genérico que después se traduce al del dispositivo específico. Para poder adaptar el terminal abstracto a un dispositivo específico se parte de la existencia del device driver correspondiente.Por encima del sistema de ventanas se encuentra la caja de herramientas o toolkit que contiene los elementos gráficos o widgets más usados, como botones, barras de menú, barras de desplazamiento, iconos, campos de entrada y de salida de varios tipos, y mensajes de error, de ayuda, etc.Por encima del toolkit puede haber herramientas que ayuden al diseñador a utilizar la juego de herramientas. Las herramientas de alto nivel son normalmente un conjunto de herramientas visuales y de lenguajes de programación que permiten desarrollar aplicaciones utilizando el toolkit inicial.

Sistemas basados en ventanas y gestores de ventanasUn sistema basado en ventanas permite disponer de diferentes contextos (aplicaciones), restringiéndolos a porciones de pantalla (ventanas), y compartiendo los recursos del ordenador (dispositivos de entrada, memoria, etc.). Estos sistemas suministran:

Modelo de entrada. El usuario interacciona sobre ventanas y sus acciones se transmiten a la aplicación correspondiente mediante eventos que posteriormente serán interpretados.

Modelo gráfico. La aplicación especifica la salida gráfica y el sistema de ventanas garantiza que esta se produce sobre su ventana correspondiente.

Gestión de ventanas. Ofrece una gestión simple de las ventanas por parte del usuario: abrir, cerrar, dimensionar, etc.

Estilo de presentación. Determina la apariencia general y el modo de interacción (look&feel).

Los sistemas de ventanas generalmente están implementados sobre parte del sistema operativo, permitiendo llevar a cabo varias actividades simultáneamente en distintas posiciones de la pantalla, es decir, ofreciendo capacidad de multiproceso. Otra ventaja adicional es que suministran una interfaz de alto nivel

8 La interacción persona-ordenador

con el ratón, teclado y pantalla. Además permiten que el código de la aplicación sea portable, siempre que esté soportado por el mismo gestor de ventanas.Como ejemplos de gestores de ventanas cabe mencionar los más significativos por su implantación en el mercado: MS (windows), X (unix).

MS WindowsEs una familia de sistemas operativos de la empresa Microsoft que se han convertido en estándares de facto debido a su gran difusión. Todos ellos presentan un único tipo de interfaz de usuario de tipo WIMP que ofrece la posibilidad de personalizarse.

X–WindowsEl sistema de ventanas X–Windows se ha convertido en el estándar industrial dentro del entorno UNIX para aplicaciones basadas en ventanas. Uno de los factores diferenciales de X–Windows respecto de Windows por ejemplo, es que no se restringe a un único estilo de interfaz de usuario, sino que permite un conjunto de ellos.

Sistemas de ventanas de software libreDentro de este apartado aparecen como sistemas líderes KDE y Gnome. En ambos se trató en un comienzo de proporcionar un entorno de escritorio para los sistemas libres, pero han pasado a ofrecer una importante colección de herramientas, librerías y componentes para el desarrollo de aplicaciones en sistemas Unix. Se podrían calificar como herramientas de alto nivel ya que la granularidad de sus componentes supone un nivel por encima de los elementos gráficos habituales como puedan ser ventanas, botones e iconos.

Juegos de herramientas o ToolkitLos juegos de herramientas (toolkit) suministran al programador rutinas de alto nivel que definen técnicas de interacción usuales denominadas controles o widgets. Algunos ejemplos son: botones, entrada de literales, ventanas pull–down, pop–up, iconos, deslizadores, formularios para introducción de datos. Podemos crear elementos estructurados en jerarquías, como pueden ser los menús en cascada. Cada widget posee una apariencia específica (look) y comportamiento (feel), junto a un conjunto de rutinas para manipular su configuración. Ejemplos de juegos de herramientas son OSF Motif, Windows SDK, Librerías gráficas como las de GKS, PHIGS, Visual C o Tcl/Tk.Los juegos de herramientas suponen una ayuda para el desarrollo de la interfaz gráfica de usuario, lo que sería el nivel de presentación de Seehim y PAC, o la vista de MVC, y no soporta directamente datos de la aplicación. La aplicación se realiza normalmente empleando lenguajes de programación como C,C++ o Java, donde se integran las llamadas a elementos de la interfaz de usuario. El desarrollador introduce en el programa los controles (widgets) para manejar las entradas del usuario, y les asocia un código (callbacks) específico de la aplicación.El esfuerzo de construcción de interfaces de usuario basados en juegos de herramientas es grande ya que implica una gran carga de programación, por lo que es fácil cometer errores. Además no existe facilidad para el prototipado rápido, ya que es necesaria una fase de compilación previa.Por otro lado, los juegos de herramientas son cada vez más complejos y los entornos de programación donde se emplean requieren experiencia y mucho tiempo de aprendizaje, por lo que el mantenimiento de la interfaz se complica.Situados por encima de los juegos de herramientas aparecen los entornos denominados WYSIWYG (What you see is what you get – lo que ves es lo que obtienes) para la creación de interfaces gráficas de usuario, que como principal ventaja presentan la del prototipado rápido, pero que además generan directamente código enlazado con el juego de herramientas nativo (Motif,

Herramientas 9

Windows, etc.). Por ejemplo: X–Designer (para Motif), Zinc Software (Windows), XF (TK) y VisualBasic.El modo de trabajar con este tipo de entornos consiste habitualmente en que el diseñador selecciona elementos de una paleta los controles, los coloca en la pantalla y, mediante un formulario, ajusta sus atributos para determinar su apariencia y comportamiento. De esta forma, el diseñador puede evaluar la interfaz conforme la va diseñando.Dentro de este apartado se pueden incluir también los UIMS (User Interface Management System). Un UIMS es un conjunto de herramientas que permiten al diseñador crear una interfaz de usuario completa sin necesidad de usar un lenguaje de programación tradicional. Para ello ayudan a especificar, implementar, probar y mantener una interfaz de usuario. Este tipo de herramientas permiten el diseño interactivo, y como en el resto de juegos de herramientas, generan el código correspondiente para la plataforma deseada. Se basan en el concepto de independencia, en la separación de los aspectos de diseño lógico de la implementación, como ya se vio en el modelo MVC. Además, soportan un conjunto de elementos de interacción que permiten al diseñador construir la presentación en pocas líneas, evitándole trabajar al nivel de programación. De esta forma se obtienen también las siguientes ventajas:

1) Mejorar la productividad del desarrollo de la interfaz, acortando tiempo de desarrollo y obteniendo una producción mas elegante. La fase de producción se hace más rápida y sencilla.

2) El desarrollador de interfaces sólo se dedica a la parte creativa, mientras que la fase de programación reside en el propio UIMS.

3) Mejorar calidad de interfaces debido a su extensibilidad, portabilidad y sobre todo fácil depuración.

Ejemplo de este tipo de sistemas son Open Look, OSF Motif, MacApp, Windows, OS/2, que generalmente están compuestos de un editor interactivo para la interfaz gráfica y un lenguaje de alto nivel para la especificación del comportamiento de la interfaz. En su día, los dos sistemas más populares fueron Motif y Open Look. En ambos casos se trataba de sistemas para el desarrollo de interfaces sobre sistemas de ventanas X–windows.Motif está diseñado de acuerdo con las normas CUA (Common User Access) que definen la asociación de comandos a letras, lo que permite una transición inmediata de los entornos PC a una estación de trabajo. La compatibilidad entre las normas CUA permite una equivalencia de teclado para entornos sin ratón. El entorno de desarrollo de Motif incluye el juego de herramientas Motif y el lenguaje UIL.Open Look es un estándar basado en un diseño de AT&T bastante peculiar, por ejemplo las barras de desplazamiento utilizadas en Open Look, diferentes de las utilizada en otros sistemas, utilizan la imagen de un ascensor en un cable con anclas superior e inferior.

4 Herramientas de diseño y construcción de IUEl diseño y desarrollo de una aplicación y de su interfaz son actividades que tienen lugar de forma simultánea. Aunque sean dos partes del sistema final que deben gozar del mayor grado de independencia entre ellas, ambas se ven inmersas en el desarrollo de un sistema final para el que se ha decidido, normalmente de antemano, el lenguaje de programación que se va a utilizar.En este apartado se verá en detalle el caso del lenguaje de programación Java ya que la orientación a objetos es el paradigma de programación que se podría

10 La interacción persona-ordenador

denominar vigente en la actualidad y con una gran difusión en el mercado. Además, la portabilidad de este lenguaje hace que sea utilizable sobre casi cualquier plataforma.En la primera parte se describe en detalle la librería gráfica de Java y en la segunda se introduce lo que probablemente será el futuro de los sistemas interactivos entre otros: los componentes.

Herramientas de programaciónJava dispone del AWT (Abstract Window Toolkit), una librería, o paquete en terminología Java, que incluye elementos gráficos en forma de clases incluidas en el núcleo del JDK (Java Development Kit). El paquete AWT proporciona los componentes básicos para el desarrollo de aplicaciones gráficas, tales como botones, menús, listas, cajas de texto, etc. En su primera versión esto, que no es poco, era todo. Con ello se podía ejecutar el mismo programa, sin necesidad de recompilarlo, en un sistema operativo MacOS, en Windows o en una estación Unix con X–Windows. Con la aparición de la versión 1.1 del JDK se añadieron nuevas funcionalidades. Por ejemplo, un mecanismo de tratamiento de eventos, la transferencia de información gráfica entre aplicaciones, soporte para el desarrollo de componentes ``ligeros'' que consumen menos recursos, etc. El inconveniente fue que las modificaciones necesarias para añadir estas funcionalidades supusieron un cambio radical en el modelo de programación de las aplicaciones gráficas, haciendo incompatibles las aplicaciones desarrolladas con JDK 1.0 con las del JDK 1.1.La nueva versión del AWT, la 1.2, está formada por seis paquetes:

java.awt: Funcionalidad básica java.awt.color: Clases encargadas de los colores java.awt.datatransfer: Soporte para la transferencia de información java.awt.dnd: Funcionalidades para drug–and–drop java.awt.event: Gestión de eventos java.awt.font: Soporte para fuentes java.awt.geom: Soporte para geometría en dos dimensiones java.awt.im: Entorno de lectura (input method) java.awt.image: Manipulación de imágenes java.awt.print: Sistema de impresión

El funcionamiento de AWT se basa en delegar gran parte de su funcionalidad en componentes nativos (peers). Las clases de AWT simplemente “empaquetan'' las clases nativas. Esta decisión de diseño facilitó el rápido desarrollo de las interfaces gráficas de Java. A cambio, el modelo resulta difícil de trazar y en algunos casos de entender.

Herramientas basadas en componentesLa creciente demanda de desarrollo de aplicaciones hace indispensable establecer dos niveles de programadores: aquellos que conocen lenguajes de programación y tienen experiencia en su uso, y aquellos que conocen los entornos de ventanas desde el punto de vista del usuario pero solo tienen conocimientos básicos de programación o carecen de experiencia.Una posibilidad para ampliar a un mayor número de personas el desarrollo de sistemas es la utilización de componentes. Los componentes en Java se denominan JavaBeans. Un JavaBean, o un Bean, es una porción de software reutilizable que se muestra 'empaquetado' a través de una interfaz visual y con el que se puede trabajar también de forma visual gracias a las herramientas gráficas disponibles que simplifican su uso y facilitan su integración dentro de aplicaciones más grandes.

Herramientas 11

La herramienta que se utiliza para el desarrollo de JavaBeans es el Beans Development Kit (BDK) que incluye la BeanBox para poder probar los Beans desarrollados manejándolos de forma visual.

Herramientas de autorLas herramientas de autor tienen la finalidad de servir como elemento de escritura y de edición para los autores de aplicaciones interactivas. Estos autores son en la mayoría de los casos los programadores del sistema que se han reconvertido, mezclando las labores propias de la implementación con otras más creativas necesarias para este nuevo tipo de escritura y edición, en la que contenidos de naturaleza diversa se funden formando un discurso multimedia.Las herramientas de autor proporcionan una gran variedad de servicios que dependen del entorno en el que el autor trabaje y del tipo de aplicación que quiera desarrollar. Desde el punto de vista de la interfaz, la utilización de lenguajes visuales de comunicación, en los que la manipulación directa de objetos, las cajas de diálogos y los menús desplegables son las formas más usuales para la interacción persona–ordenador, es la fórmula más usada en este tipo de herramientas, debido a que el autor puede ignorar aspectos de programación (por ejemplo, reservar espacios de memoria para los punteros) que no son interesantes para su cometido.Son muchas las características que tienen cumplir las herramientas de autor para que ayuden en el proceso de creación [DIA96]. En primer lugar, una exigencia básica para todo entorno de autoría es la existencia de mecanismos para preparar y manipular material multimedia. La tecnología no debe mermar las capacidades expresivas y creativas del autor, sino que debe permitirle emplear imaginativamente la información. Así, por ejemplo, el autor puede necesitar analizadores ortográficos para revisar sus escritos, editores de dibujo integrados para preparar sus gráficos y aplicaciones para manipular el material videográfico. Las herramientas actuales generalmente incorporan estos mecanismos facilitando la labor del autor.Además, estas herramientas deben permitir el uso de contenidos de información que sean capaces de reaccionar ante eventos, ya sean producidos desde el exterior (v.g., el movimiento del ratón) o desde el interior (v.g., un intervalo de tiempo desde el inicio de la sesión) del sistema interactivo. También, se debe poder asociar atributos o metadatos a estos contenidos, ya sean semánticos o de interfaz, para que el autor pueda controlar tanto su significado en el contexto como su apariencia.Además, las herramientas de autor deben disponer de funciones con las que poder construir, de forma sencilla, mecanismos de ayuda para la interacción (v.g., mecanismos de navegación), así como comandos para la búsqueda de información, ya sea por medio de cadenas de caracteres, de consultas con un lenguaje de interrogación, o de algún mecanismo más complejo, como podría ser la utilización de los metadatos mencionados anteriormente.Normalmente las herramientas de autor se clasifican por el modelo de información que utilizan, ya que habitualmente simulan un espacio conocido por el autor y el lector, es decir, utilizan una metáfora como base del desarrollo. Al emplear algo conocido se facilita la labor del autor y del lector en el desarrollo y uso de la aplicación en la mayoría de los casos. Ejemplos de uso de metáforas como modelo de información son: HyperCard que utiliza una pila de tarjetas, ToolBook que se basa en un libro con páginas y Macromedia Director que usa un escenario con actores.Por otro lado, las herramientas de autor se pueden clasificar en función de cómo se describe el comportamiento de los elementos existentes en la aplicación [VÄÄ94], pudiendo ser: basados en guiones (scripts), que son aquellos en los que autor escribe guiones de comportamiento en los contenidos con los que interactúa el usuario (v.g., ToolBook); basados en iconos, que incluye a aquellas herramientas que ofrecen al autor una serie de iconos para definir la secuencia de aparición de

12 La interacción persona-ordenador

los contenidos en la aplicación (v.g., Authorware); y basados en el tiempo, que referencian a los sistemas que basan su desarrollo en una línea de tiempo sobre la que se sincroniza y alinean los contenidos (v.g., Macromedia Director).

Entornos virtualesEn esta sección se presentan algunas herramientas que hacen posible la creación de mundos virtuales de escritorio, denominados así porque permiten al usuario sumergirse y explorar un espacio tridimensional desde su ordenador y con el ratón, sin necesidad de utilizar ningún dispositivo hardware especial, de manera que se acerca esta tecnología a un gran número de usuarios. No obstante, si se dispone del hardware apropiado la ejecución se acelera en gran medida, ya que el cálculo de cómo se presenta el mundo se llevará a cabo en dicho hardware, liberando al procesador de ese proceso.En primer lugar, se puede mencionar QuickTime VR, la propuesta de Apple para generar espacios trimidensionales. Con este software, los diseñadores pueden convertir de forma muy simple imágenes bidimensionales en mundos virtuales con escenas tridimensionales y componentes interactivos. Su facilidad de uso reside en que se asume la metáfora de trabajo de "apuntar y pinchar" (point–and–click) y, además, se beneficia de la intuitiva interfaz de usuario propia de Mac. Los mundos virtuales generados con esta herramienta pueden ser utilizados en distintas plataformas y, de hecho, pueden verse con cualquiera de las aplicaciones capaces de ejecutar películas quicktime. No obstante, y a diferencia de las dos otras opciones que se presentarán a continuación, ni el software de creación, como por ejemplo QuickTime VR Authoring Studio, VR Worx 2.0 o Corel Photo–Paint 8, ni la aplicación generada son independientes de la plataforma. En la Figura 1 se muestra un ejemplo de utilización de esta tecnología para realizar una visita virtual por la ciudad de Vancouver.

Figura 1 Una visita virtual por Vancouver recorriendo sus calles y usando un mapa (http://www.virtuallyvancouver.com)

Otra posibilidad consiste en utilizar VRML (Virtual Reality Modeling Language ISO/IEC 14772), un lenguaje con el que pueden definirse tanto el espacio de coordenadas del mundo virtual, como los objetos tridimensionales y multimedia que lo componen, los comportamientos de esos objetos y enlaces a otras aplicaciones. Este lenguaje está pensado para ser utilizado en entornos distribuidos como el web, para lo cual hace posible que un mundo virtual se componga de varios ficheros enlazados o incluidos, hace uso de estándares establecidos de ISO e Internet para otros formatos de fichero y proporciona una sintaxis compacta. Sin embargo, muchos diseñadores pueden encontrar complicado el uso de VRML, puesto que se trata de un lenguaje de modelado con el que se especifican los objetos geométricos y sus características. Para facilitar esta tarea, existen algunas herramientas que permiten dibujar los mundos tridimensionales de una forma más intuitiva, tales como 3D Studio, y, posteriormente, traducirlos a una especificación VRML. Por último, para visualizar esta información a través de navegadores (v.g. Netscape) se pueden utilizar diversos visores como son Cosmo Player (http://www.sgi.com/software/cosmo) o Cortona (http://www.parallelgraphics.com /products/cortona). En la Figura 2 se muestra un ejemplo de realidad virtual desarrollada con VRML y que se visualiza en los dos visores mencionados. Como se puede apreciar, las opciones de movimiento por el mundo tienen distinta representación en ambos visores.

Herramientas 13

Finalmente, la API de javaSoft denominada Java 3D pertenece a un conjunto de APIs que han sido desarrolladas con el fin de ofrecer un entorno en que incluir en las páginas web todo tipo de información multimedia. JAVA 3D presenta dos ventajas fundamentales: al igual que ocurría con VRML, es independiente de plataforma de manera que el diseñador puede aprovecharse del hecho de escribir un único código ejecutable en cualquier sitio; y, además, al contrario que QuickTime VR o VRML no requiere que el usuario instale un plug–in en su navegador web para utilizar el mundo virtual. Esta API se puede utilizar para crear aplicaciones tridimensionales o applets 3D para el web, consiguiendo en ambos casos una gran eficiencia en la utilización de grandes mundos virtuales que, además, pueden incluir sonido espacial tridimensional de forma que se ofrezca al usuario una sensación de auténtica inmersión en el mundo virtual. El paradigma de programación subyacente, la programación orientada a objetos, ofrece al diseñador abstracciones de alto nivel que le permiten crear su escena virtual pensando en objetos geométricos, en vez de en formas particulares (por ejemplo, triángulos o cuadrados), y componiéndolos en el espacio sin necesidad de tener en cuenta la forma de optimizar el código para conseguir una mayor eficiencia.

Figura 2 Una visita virtual por el centro de empresas del Ayuntamiento de Cádiz utilizando el visor Cosmo Player (izquierda) y Cortona (derecha)

Lenguajes de marcadoEn el mundo de los documentos en papel, el término marcado hace referencia a la manera en la que el editor anota los manuscritos con especificaciones tipográficas y otros datos sobre su presentación. En los documentos electrónicos, el marcado es el término empleado para describir los códigos, denominados también etiquetas, añadidos al texto electrónico, que definen la estructura y el formato en el que tiene que aparecer [BRY88]. Además, el marcado puede ser utilizado para propósitos muy diferentes, como son la escritura, la impresión, el intercambio, la presentación de pantallas, etc. Los sistemas de autoedición, las bases de datos documentales, los sistemas hipermedia, y otras aplicaciones orientadas al documento se pueden aprovechar de estas etiquetas, de manera que los archivos no sólo sean conjuntos de contenidos sino que tengan una semántica asociada.El lenguaje de marcado define un conjunto de signos y reglas con los que etiquetar los documentos, e históricamente han aparecido tantos como productos había en el mercado. La gran variedad de lenguajes de marcado y su patente incompatibilidad constituyen la causa de los problemas que se plantean al intercambiar un documento. Los lenguajes estándar proporcionan una manera de solventar esta situación, ya que son independientes de la aplicación y de la plataforma hardware [RAA93], y emplean el código ASCII, en la mayoría de los casos, para marcar el documento.Cuando se habla de lenguajes de marcado, es importante distinguir entre la estructura lógica y física del documento. La estructura lógica está formada por las distintas partes que lo componen y por sus relaciones. Por ejemplo, un documento puede constar de una introducción, seguida de una lista de capítulos formados a su vez por secciones, y finalizar con una conclusión. La estructura física, en cambio, indica la apariencia del documento, ya sea en el papel o en la pantalla, incluyendo sus componentes físicos (v.g., páginas), la situación de los elementos (v.g., gráficos) y la tipografía empleada. En la Figura 3 [DIA96], se pueden ver a la

14 La interacción persona-ordenador

izquierda algunos de los componentes que describen lógicamente un documento y a la derecha algunos de los físicos.Mientras que en el material impreso es imposible separar las dos estructuras, en los documentos electrónicos la información sobre la estructura lógica y la física se puede almacenar independientemente. Esto es posible gracias a los lenguajes de marcado genéricos [BRY88], que permiten etiquetar los diferentes componentes o elementos lógicos del documento manteniendo separadas las instrucciones de procesamiento, que se ejecutarían mediante un programa destinado a dar formato al texto. En otras palabras, el marcado genérico describe la estructura de un documento y sus atributos, sin especificar el proceso que se debe realizar sobre él. Esto supone que el mismo documento se puede presentar de muchas maneras, de acuerdo con las normas de estilo que se le apliquen.

Figura 3 Componentes lógicos y físicos de un documentoHay otros tipos de marcado, denominados específicos [BRY88], que no mantienen esta separación. El marcado específico contiene instrucciones relativas a la apariencia física del documento, por lo que depende de la aplicación que se utilice para procesarlo. Ejemplos clásicos de marcado específico son Script, nroff o TeX y los usados por los procesadores de texto, tales como Word o WordPerfect.La publicación electrónica se puede beneficiar de la flexibilidad, velocidad y eficiencia que se consigue cuando los documentos están disponibles en un formato de marcado genérico [SMI92]. El editor puede producir fácilmente múltiples presentaciones, ya que al documento se le pueden asociar múltiples estilos sin tener que introducir de nuevo la información, con el consiguiente ahorro de costes y tiempo. Un ejemplo de este tipo de lenguaje es SGML (Standard Generalized Markup Language), que se ha convertido en los últimos años en la forma más habitual de intercambio de información debido fundamentalmente a su flexibilidad y generalidad. SGML es la base para la definición de lenguajes utilizados en aplicaciones hipermedia en la red, tales como HTML, XML, etc.

SGMLSGML es un ejemplo de lenguaje genérico que apareció con el identificador 8879 como norma ISO (International Organization for Standardization) en 1986 [WRI92]. La comunidad editorial fue la que dio origen a esta norma, al considerar que la flexibilidad en el diseño de los documentos era de máxima importancia. El objetivo que perseguía era proporcionar una manera normalizada de transmitir los documentos en un formato adecuado para los procesos de edición e impresión [BRO89]. SGML es apropiado para describir texto altamente estructurado, aunque también se pueden incluir en los documentos otros elementos, como por ejemplo diagramas y gráficos, independientemente de su formato de codificación.

Herramientas 15

SGML contiene las reglas para crear una infinita variedad de lenguajes de marcado, pero no describe el formato de los documentos marcados [HER94]. Una definición similar, dada por MACLEOD et al. [MAC91], clasifica a SGML como un sistema para especificar lenguajes de marcado, es decir, un metalenguaje. Esto hace posible que, mediante la utilización de una definición de tipo de documento (denominada DTD Document Type Definition), se pueda especificar la estructura lógica de una clase de escrito.Una DTD es una definición formal que indica qué elementos se incluyen como contenidos de los documentos y en qué orden. Cada elemento en el documento se marca mediante una etiqueta de comienzo y otra de final. Estas etiquetas vienen especificadas mediante un identificador genérico, que define el tipo del elemento (por ejemplo, párrafo, cabecera o figura) y unas características, o atributos, que cualifican al identificador. En concreto una DTD define:

1) los identificadores genéricos de los elementos que se permiten en un tipo de documento;

2) para cada elemento, los posibles atributos y sus rangos de valores, así como el que toma por defecto; su estructura y su contenido, incluyendo los subelementos que pueden ocurrir y en qué orden.

Una DTD considera un documento como un árbol, cuya raíz es el propio documento. Un ejemplo de cómo podría aparecer un elemento en una DTD se puede ver en la Figura 4. Libro, páginas previas, cuerpo y páginas finales son los identificadores genéricos de los elementos. El elemento libro se define mediante el grupo (páginas previas, cuerpo, páginas finales). Cada ítem en el grupo necesita, a su vez, una mayor definición, hasta llegar a elementos terminales que no se subdividen en otros.

<!ELEMENT libro (páginas previas, cuerpo, páginas finales)> Figura 4 Definición de un elemento en una DTD

5 Ejemplos de lenguajes de marcado en la redA partir de la definición de SGML se han generado diversos lenguajes de marcado que sirven, o han servido, para el desarrollo de aplicaciones hipermedia. Es cierto que normalmente estos lenguajes no se utilizan directamente, sino que normalmente se usan herramientas de autor que generan el código en algunos de los lenguajes que se mencionan a continuación (v.g., Macromedia DreamWeaver). De esta forma el programador no se preocupa ni de la sintaxis ni de la semántica asociada a los códigos concretos si no que mediante lenguajes visuales establece la estructura, el contenido y la apariencia de los hiperdocumentos que conforman su aplicación. Algunos de los lenguajes de marcado más conocidos son:

HTML (Hypertextual Markup Language). Es una aplicación de SGML que incluye tipos de documentos predefinidos. Por ello, todos los documentos de tipo HTML contienen los mismos elementos y los mismos atributos, es decir todos los documentos de este tipo tienen la misma estructura pero no los mismos contenidos. La última versión de HTML es la 4.02 siendo una recomendación no una especificación ya que no se llegó a un acuerdo total sobre ella. Esta norma ha ido desvirtuándose de tal manera que además de elementos conceptuales como pueden ser los enlaces, contiene también elementos de presentación (v.g., el elemento para poner en negrita un texto).

XML (Extensible Markup Language). Es una aplicación de SGML, lo que significa que en su especificación se indican como se deben describir los elementos que participan en el hiperdocumento pero no los elementos en sí. Por tanto, cuando se quiere describir un documento mediante XML hay

16 La interacción persona-ordenador

que describir en primer lugar el tipo de documento en que se basa, es decir la DTD, y a continuación los contenidos concretos asociados a cada elemento. Un ejemplo de construcción de aplicaciones con XML es el desarrollo de normas para tipos concreto de documentos, como puede ser un libro electrónico. OpenEBook es una iniciativa de desarrollo de una DTD para libros electrónicos en la que numerosas empresas del sector bibliográfico están trabajando para conseguir que con una misma plataforma se puedan leer, comprar y distribuir libros electrónicos que tengan un formato común.

XHTML (Extensible Hypertext Markup Language). Es una nueva definición de HTML a partir de XML. Este lenguaje se basa en la redefinición de las DTDs de HTML versión 4 mediante XML lo que permite entre otras cosas que los documentos siguiendo XHTML se puedan visualizar tanto en navegadores de HTML como en los de XML. Además, permite la inclusión de programas dentro de su contenido siguiendo el modelo de objetos que define la especificación DOM (Document Object Model), la cual permite actualizar y modificar los contenidos, estructura y estilo de los documentos de forma dinámica.

HyTime (Hypermedia/Time–Based Structuring Language). Es una extensión de SGML que especifica un conjunto de conceptos básicos con los que se puede definir la estructura lógica de documentos hipertextuales y multimedia [DER94]. HyTime normaliza aquellos mecanismos que se refieren a la localización de porciones de documentos hipermedia y sus componentes multimedia de información, incluyendo enlaces, alineamiento en el espacio y sincronización en el tiempo, es decir, proporciona una manera homogénea de enlazar a un documento cualquier tipo de elemento, en cualquier parte y en cualquier instante. Sirve como base de intercambio de informaciones hipermedia, independientemente de la aplicación que las haya creado, y se ocupa de normalizar la estructura del documento y la identificación de los objetos de información que lo conforman. HyTime, por tanto, no establece los contenidos del hiperdocumento, ni la codificación de la información, ni los objetos, ni la aplicación que trabaja sobre ellos, ni arquitecturas de documentos particulares, ni tipos de enlaces, ni tipos de documentos. Debido a la dificultad en su uso, esta norma no ha sido utilizada de una forma masiva, aunque muchas de sus ideas se encuentran en las normas que en la actualidad se están imponiendo.

SMIL (Synchronized Multimedia Integration Language). Es un lenguaje basado en XML para la definición de aplicaciones multimedia interactivas, de manera que un autor puede describir el comportamiento temporal de presentaciones multimedia, asociar enlaces a contenidos de cualquier tipo (v.g. vídeos, sonidos, programas, etc.) y describir la presentación en la pantalla.

Todos estos ejemplos de lenguajes de marcado se basan en la definición de la estructura de los elementos, indicando cuáles existen en el dominio del documento y cómo participan en él, es decir lo que anteriormente se ha denominado lenguajes de marcado genéricos. Pero estos lenguajes de marcado se complementan con otros lenguajes que se utilizan para describir cual es la apariencia final en el soporte físico de visualización.Un ejemplo es DSSSL (Document Style Semantics and Specification Language) que tiene como objetivo definir el nivel de presentación independientemente de los sistemas de procesamiento, con lo cual el usuario puede especificar el aspecto de cada uno de los elementos de la DTD. Este lenguaje normalmente se utiliza en combinación con HyTime indicando la apariencia de los objetos definidos en sus documentos.Otro ejemplo, de uso más extendido, es CSS (Cascading Style Sheets) que define la apariencia de los elementos HTML o XML que se muestran en un navegador Web. La idea básica en este tipo de lenguaje es el uso de la página física sobre la que se

Herramientas 17

definen algunas características de su apariencia, como puede ser la posición de un contenido o la tipografía utilizada.Un paso más adelante es XSL (Extensible Stylesheet Language) que, ampliando las ideas de los dos lenguajes anteriores y basando su descripción en XML, permite la definición de la presentación de documentos XML. El proceso de construcción consiste en dos pasos. En el primero se transforma el documento XML expandiendo el documento y calculando aquellos apartados dependientes del estilo (v.g. tipo de ordenación de una lista, inclusión de un índice de contenidos, etc.). En el segundo paso, se prepara el documento para ser presentado en el dispositivo de visualización (navegador, impresora, teléfono móvil, etc.) adaptándolo a las características propias del dispositivo.

ConclusionesExiste la necesidad de ofrecer entornos de prototipado rápido de la interacción persona–ordenador a través de la interfaz en las aplicaciones gráficas.Las herramientas de desarrollo de interfaces gráficas de usuario tienden a ofrecer elementos cada vez de más alto nivel, siendo los componentes la tendencia actual de mayor grado de abstracción.La tendencia actual hacia los desarrollos web hace que estén apareciendo herramientas que utilizan el propio web como marco de trabajo para el desarrollo de aplicaciones accesibles desde navegadores, como puede ser Zope (http://www. zope.org).

Referencias[BAE95] BAECKER R., GRUDIN J., BUXTON W. y GREENBERG S. eds. Readings in

Human–Computer Interaction: towards the year 2000, 2ª edición. Morgan Kaufman Published, 1995

[BRO89] BROWN H. «Standards for Structured Documents» en The Complete Journal, Núm. 32 (6), Pág. 505-514, 1989

[BRY88] BRYAN M. SGML An author's guide to the Standard Generalized Markup Language. Addison–Wesley, Londres, 1988

[DER94] DEROSE S. J. y DURAND D. G. Making Hypermedia Work: HyTime. Kluwer Academic Publishers Boston, 1994

[DIA96] DÍAZ P., CATENAZZI N. y AEDO, I. De la multimedia a la hipermedia. Ed. Rama, Madrid, 1996

[DIX98] DIX A., FINLAY J., BOWD G. y BEALE R. Human–Computer Interaction, 2ª edición. Prentice Hall, LSI nº 1119, 1998

[HER94] HERWIJNEN E. VAN Practical SGML, 2ª Edición. Kluwer Academic Publishers, Boston, 1994

[MAC91] MCLEOD I. A., BARNARD D. T., HAMILTON D. y LEVISON M. «SGML Documents and Non–linear Text Retrieval» en Actas de RIAO 1991, Abril 1991, Núm. 2-5, Barcelona, Pág. 226-244, 1991

[SMI92] SMITH J. M. SGML and related standards. Ellis Horwood, Nueva York, NY, 1992

[VÄÄ94] VÄÄNÄNEN K. «Metaphor–based User Interfaces for Hyperspaces» en Designing User Interface for Hypermedia (SCHULER W., HANNEMANN J. y STREIZ N. eds.), Springer Verlag, Alemania, Pág. 68-78, 1995

[RAA93] RAAIJ T. VAN «Portable, Device Independient Documents Hype or Reality» en Proceedings of Document Interoperability Conference, 16-

18 La interacción persona-ordenador

17 noviembre 1993, Londres, 1993[WRI92] WRIGHT H. «SGML frees information» en Byte, Núm. 17 (6), Pág. 279-

286, junio 1992

BibliografíaBAECKER R., GRUDIN J., BUXTON W. y GREENBERG S. eds. Readings in Human–Computer Interaction: towards the year 2000, 2ª edición. Morgan Kaufman Published, 1995BROWN H. «Standards for Structured Documents» en The Complete Journal. Núm.32 (6), Pág. 505-514, 1989BRYAN M. SGML An author's guide to the Standard Generalized Markup Language. Addison–Wesley, Londres, 1988CULWIN, F. An X/Motif Programmer’s Primer. Prentice Hall, Londres, 1994DEROSE S. J. y DURAND D. G. Making Hypermedia Work: HyTime. Kluwer Academic Publishers BostonDÍAZ P., CATENAZZI N. y AEDO, I. De la multimedia a la hipermedia. Ed. Rama, Madrid, 1996DIX A., FINLAY J., BOWD G. y BEALE R. Human–Computer Interaction, 2ª edición. Prentice Hall, LSI nº 1119, 1998HERWIJNEN E. VAN Practical SGML. Kluwer Academic Publishers, Dordretch, 1990HERWIJNEN E. VAN Practical SGML, 2ª edición. Kluwer Academic Publishers, Boston, 1994MCLEOD I. A., BARNARD D. T., HAMILTON D. y LEVISON M. «SGML Documents and Non–linear Text Retrieval» en Actas de RIAO 1991, Abril 1991, Núm. 2-5, Barcelona, Pág. 226-244, 1991SMITH J. M. SGML and related standards. Ellis Horwood, Nueva York, NY, 1992VÄÄNÄNEN K. «Metaphor–based User Interfaces for Hyperspaces» en Designing User Interface for Hypermedia (SCHULER W., HANNEMANN J. y STREIZ, N. eds.), Springer Verlag, Alemania, Pág. 68-78, 1995RAAIJ T. VAN «Portable, Device Independient Documents Hype or Reality» en Proceedings of Document Interoperability Conference, 16-17 noviembre 1993, Londres, 1993WRIGHT H. «SGML frees information» en Byte, Junio 1992, Núm.17 (6), Pág. 279-286, 1992

Herramientas 19