Construcción de Interfaces a Usuario - ©1999 Construcción de Interfaces a Usuario: Herramientas de Construcción

Construcción de Interfaces a Usuario - ©1999 Contenidos 4 Herramientas de construcción de interfaces –Requisitos –Basadas en Lenguajes Diagramas de transición, Gramáticas, Eventos, Declarativas, Restricciones, Programación Visual –Frameworks de Aplicación –Herramientas Basadas en Modelos Cajas de diálogo, interfaces completas –Especificación Gráfica Directa Prototipación, Cards, Interface Builders, By demonstration –Comparación –Evaluacion

Construcción de Interfaces a Usuario - ©1999 Herramientas de construcción de interfaces 4 La programación a nivel de toolkit es bastante dificil –Necesidad de contar con herramientas de alto nivel para facilitar la producción de software para la UI 4 Las herramientas pueden ser utilizadas en distintos momentos –Durante el diseño: asisten al diseñador de la IU ej. Editores de layouts, procesadores de lenguajes de descripción de IU –Durante la ejecución: administran la ejecución de la IU Generalmente incluyen un toolkit –Después de la ejecución: facilitan la evaluación y depuración de la IU Pocas herramientas lo incluyen

Construcción de Interfaces a Usuario - ©1999 Herramientas de construcción de interfaces 4 ‘User Interface Management Systems’ (UIMS) o ‘User Interface Development Systems’ (UIDS) –Soporte completo para el desarrollo del software de la IU 4 Herramientas de prototipación –Permiten ver rápidamente cómo será la apariencia y comportamiento de la IU 4 ‘Interface Builders’ –Disponen espacialmente los widgets de una IU –Crean menúes, cajas de diálogo, formularios 4 Algunos estudios muestran que el desarrollo de IU con herramientas de alto nivel es 10 a 50 veces más rápido que utilizando un toolkit

Construcción de Interfaces a Usuario - ©1999 Motivación 4 La calidad de las interfaces será mayor –Los diseños pueden ser prototipados rapidamente, antes de escribir el código de la aplicación –Es más sencillo incorporar cambios descubiertos durante el test con el usuario –Pueden existir múltiples interfaces para la misma aplicación –Puede dedicarse un esfuerzo mayor a la construcción de una herramienta, ya que la herramienta será utilizada con muchas aplicaciones –Aplicaciones diferentes tendrán interfaces más consistentes, si son creadas con la misma herramienta –Una buena herramienta facilitará la participación de diversos especialistas en el diseño de la interfaz

Construcción de Interfaces a Usuario - ©1999 Motivación 4 El código de la IU será más sencillo y económico de mantener. –Las especificaciones de la interfaz pueden ser representadas, validadas y evaluadas más facilmente –Existe menos código para escribir, ya que una alta porción es provista por las herramientas –Habrá una mejor modularización, debido a la separación de la componente interactiva de la aplicación –El nivel de experiencia necesaria para los diseñadores de interfaces e implementadores será menor, ya que la herramientas ocultan muchas de las complejidades del sistema subyacente –La confiabilidad de la interfaz será mayor, ya que el código será creado automáticamente a partir de una descripción de alto nivel –Será mas facil portar una aplicación a un hardware diferente ya que las dependencias de los dispositivos están ocultadas por la herramienta

Construcción de Interfaces a Usuario - ©1999 Qué deben proveer las herramientas? –Asistencia en el diseño de la interfaz, dada una especificación de las tareas a realizar por el usuario –Ayuda en la implementación de la interfaz, dada una especificación del diseño –Ayuda en la evaluación de la interfaz, una vez que fue diseñada y proponer mejoras –Creación de interfaces fáciles de usar –Permitir al diseñador analizar rápidamente diseños diferentes –Permitir el diseño e implementación de IU por no programadores –Permitir al operador la adaptación de la IU a sus preferencias –Proveer portabilidad entre diferentes máquinas y dispositivos –Facilidad de uso

Construcción de Interfaces a Usuario - ©1999 Técnicas utilizadas en las herramientas 4 Muchas áreas corresponden a investigaciones actuales –Lenguajes orientados a objetos –Restricciones: relaciones declaradas por el programador, y mantenidas por el sistema –Dibujo de objetos específicos de la aplicación, y asignar o demostrar su comportamiento –Creación automática de partes de una interfaz, a partir de una especificación –Inclusión de soporte para Undo, aborts, ayudas,... –Asistencia en la evaluación de la interfaz resultante

Construcción de Interfaces a Usuario - ©1999 ‘User Interface Management Systems’ (UIMS) 4 Soporte para todas las fases del proceso de desarrollo de interfaces –Diseño, ejecución y evaluación 4 Generalmente, incluyen: –Un framework de aplicación Provee el comportamiento común de todas las aplicaciones interactivas –Algún mecanismo de especificación de la interfaz Generalmente, representan el diálogo en un lenguaje formal Diagramas de transición, gramáticas, eventos

Construcción de Interfaces a Usuario - ©1999 Herramientas basadas en lenguajes 4 La interfaz es especificada utilizando un lenguaje de propósito especial –El lenguaje puede tomar muchas formas  Sólo pueden ser utilizadas por programadores profesionales  Algunos programadores no están predispuestos a aprender un nuevo lenguaje sólo para especificar la IU  Es más natural especificar la IU utilizando un editor gráfico

Construcción de Interfaces a Usuario - ©1999 Diagramas de transición de estados 4 Conjunto de estados y arcos –Los arcos están rotulados con los tokens de input que producen una transición a otro estado –Pueden incorporarse invocaciones a procedimientos de la aplicación y outputs en la presentación (feedback).

Construcción de Interfaces a Usuario - ©1999 Diagramas de transición de estados 4 Extensiones: –Sub-diagramas Facilitan la modularización y simplifican las redes grandes –Estados especiales para administrar ayudas, aborts, undo, etc. Transiciones de “escape” para abortar un diálogo Subdiálogos para excursiones temporarias a otros diálogos, retornando posteriormente al mismo lugar –ej. ayudas Transiciones por omisión –si no son indicadas explícitamente en el grafo –Redes de transición “aumentadas” Variables locales “Guardas”: determinan la legalidad de las transiciones “Transiciones condicionales”: determinan el destino de la transición

Construcción de Interfaces a Usuario - ©1999 Diagramas de transición de estados  Enfatiza la secuencia temporal de los eventos del usuario  Si son pequeños, son naturales y fáciles de entender  Apropiados para algunas partes de las interfaces gráficas: Comportamiento de widgets, transiciones entre cajas de diálogo, flujo global de la aplicación  Tratamiento de eventos sin un orden dado  Problemas para representar IU de manipulación directa El usuario posee una amplia cantidad de acciones alternativas para realizar Grandes cantidades de arcos saliendo de cada nodo  No pueden manejar IU donde se puede operar sobre varios objetos a la vez –Han sido muy estudiados, pero no han resultado exitosos. –Utilizados en algunos UIMS: Investigación: Reaction Handler (Newman), RTN (Jacob) Comercial: RAPID/USE, VAPS

Construcción de Interfaces a Usuario - ©1999 Gramáticas libres de contexto 4 Idea general: utilizar los conceptos de los generadores de parsers utilizados en el desarrollo de compiladores –ej. BNF, Syngraph –Orientadas para el procesamiento de cadenas con una estructura sintáctica compleja ::= cp ::= ::= | ::= A|B|C| |Z ::= - ::= i | p | r | R cp -ip file1 file2 cp -irR file1 file2 –Poseen básicamente el mismo poder que los diagramas de transición

Construcción de Interfaces a Usuario - ©1999 Gramáticas libres de contexto 4 Extensiones: –Asociar acciones semánticas al procesamiento de los no terminales –Asociar tipos con los no terminales 4 Utilizadas solamente en unos pocos UIMS –SynGraph, otros utilizando YACC + LEX 4 Han sido dejadas de lado para la especificación de IU

Construcción de Interfaces a Usuario - ©1999 Gramáticas libres de contexto  Apropiadas para describir diálogos textuales que poseen una sintaxis formal Lenguajes de comandos textuales  Maneja tanto aspectos sintácticos como léxicos  Poco intuitivo para los desarrolladores  Es dificil determinar la ubicación de las acciones semánticas  Pobre recuperación de errores  No maneja output  No maneja las interfaces de manipulación directa

Construcción de Interfaces a Usuario - ©1999 Lenguajes de Eventos 4 Idea básica: diseñar un lenguaje que trate los distintos eventos recibidos del sistema de ventanas –La interfaz es diseñada en términos de los eventos de input, no como estados internos ni su sintaxis –Objetivo: administración de múltiples procesos: Múltiples dispositivos de entrada simultáneos Múltiples técnicas de interacción 4 Composición –Eventos: cualquier acción del usuario o programa (con parámetros) –Manejadores de eventos: rutinas para procesar los eventos Poseen un evento que “dispara” su ejecución Cada manejador posee una condicion que determina el tipo de eventos que podrá tratar, y cuando se encuentra en un estado activo

Construcción de Interfaces a Usuario - ©1999 Lenguajes de Eventos –El código de los manejadores puede realizar cálculos, comunicarse con la aplicación, generar nuevos eventos, cambiar el estado interno, etc. Los cálculos son arbitrarios, permitiendo que los lenguajes de eventos tengan un alto poder de expresión ej. HyperTalk on mouseUp play “boing” wait for 3 seconds visual effect wipe left very fast to black write “goodbye” end mouseUp

Construcción de Interfaces a Usuario - ©1999 Lenguajes de Eventos 4 En algunas situaciones, son llamados “sistemas de producciones” –Debido a la similitud con las reglas ‘if-then-else’ 4 Extensiones –Incorporación de variables locales (’flags’) para especificar el flujo de control (Sassafras) 4 UIMS –ALGAE (extensión de Pascal), Sassafras –HyperTalk (HyperCard) Define scripts que son ejecutados ante eventos –El éxito de HyperTalk y otras herramientas similares muestran que este enfoque es apropiado para programas pequeños y de tamaño medio.

Construcción de Interfaces a Usuario - ©1999 Lenguajes de Eventos  Pueden manejar múltiples dispositivos de input activos simultáneamente  Es conveniente para interfaces no modales, donde el usuario puede operar cualquier widget en cualquier momento  Más naturales para interfaces gráficas  Mayor poder descriptivo  Es dificil crear código correcto El flujo de control no está localizado Pequeños cambios en una parte pueden afectar muchas piezas diferentes del programa Dificil comprensión del código cuando tiene un tamaño razonable  La implementación puede ser costosa si se chequean todas las reglas  Necesidad de aprender un nuevo lenguaje de programación  Poca separación entre el código de la interfaz y el núcleo funcional

Construcción de Interfaces a Usuario - ©1999 Lenguajes declarativos 4 Objetivos: –Menor esfuerzo de programación –Mejor separación de la IU y el NF –Multiples interfaces para la misma aplicación 4 Especificación en un estilo declarativo –Adecuados para UI basadas en “formularios”, conteniendo distintos campos –Generalmente proveen areas gráficas de output que pueden ser utilizadas por la aplicación en la forma deseada –La aplicación es generalmente conectada a la IU a través de “variables” que pueden sera accedidas por ambas partes

Construcción de Interfaces a Usuario - ©1999 Lenguajes declarativos 4 Ejemplo: Cousin (1985) Soporta botones, textos, tablas, ventanas [ FormName: "File System Manager” Purpose: "For browsing and managing files” ] [ Name: "Sort by" ValueType: String DefaultValue: Name InteractionMode: CycleButton EnumeratedValues: (Name, "Last Change Date", Size) Purpose: "How the files should be sorted" Location: 10, 40 ] [ Name: Files ValueType: String DefaultSource: NoDefault MinNumber: 1 MaxNumber: 1000 InteractionMode: Table NumColumns: 4 Purpose: "List of files found matching the spec" Location: 10, 40 ]

Construcción de Interfaces a Usuario - ©1999 Lenguajes declarativos 4 Lenguajes de descripción de layouts (ej. UIL) –El código UIL puede ser editado –UIL no es un lenguaje completo: el diseñador debe escribir código C para varias partes de la interfaz ej. areas con gráficos dinámicos o widgets que cambian su apariencia y/o comportamiento 4 Han tenido bastante éxito como lenguajes intermedios para describir el layout de widgets, generados por herramientas interactivas 4 La incorporación de interacciones más sofisticadas ha producido que las especificaciones se transformen en “modelos de la aplicación” –Herramientas basadas en modelos

Construcción de Interfaces a Usuario - ©1999 Lenguajes declarativos  El diseñador de la IU no tiene que preocuparse acerca del secuenciamiento temporal de los eventos  Especifica el “qué” no el “cómo”  Especialmente útil para formularios  Separa IU - NF a través de variables  No puede cambiar dinámicamente la interfaz, de acuerdo a la dinámica de la aplicación  Las herramientas interactivas son más sencillas de utilizar para determinar el layout de widgets y sus propiedades  No pueden expresarse dependencias entre widgets  Solo pueden proveer determinados tipos de interfaces El resto de estilos deben ser explícitamente programados en las áreas gráficas provistas a los programas de aplicación  Los tipos de interacciones disponibles son preprogramados y fijos. No proveen soporte para acciones tales como dragging, rubberbanding, etc.

Construcción de Interfaces a Usuario - ©1999 Lenguajes de restricciones 4 Utilizan restricciones para definir la IU –ej. Sketchpad, ThingLab –Varios toolkits incorporan restricciones ej. Garnet, Amulet –Otros sistemas proveen interfaces de alto nivel para la especificación de restricciones ej. graphical ThingLab: el diseñador especifica las restricciones a través de conectar íconos ej. NoPump, Penguims; las restricciones son utilizadas utilizando una tabla tipo planillas de cálculo

Construcción de Interfaces a Usuario - ©1999 Lenguajes de restricciones 4 ej. Amulet Am_Define_Formula (line_selected) { if (self.Get(Am_SELECTED)) return Am_Red; else return Am_Black; } Am_Object my_line = Am_Line.Create().Set(Am_LINE_STYLE, line_selected).Add_Part(Am_Choice_Interactor.Create());

Construcción de Interfaces a Usuario - ©1999 Lenguajes de restricciones 4 Poseen un gran potencial para simplificar la tarea de programación –Sin embargo, no existen aún sistemas comerciales que las usen  Forma natural de expresar varios tipos de relaciones ej. objetos centrados, distancias entre cajas, etc.  Requiere un soporte sofisticado en tiempo de ejecución para resolverlas eficientemente  Pueden ser dificiles de expresar  Pueden ser difíciles de depurar cuando no son especificadas correctamente

Construcción de Interfaces a Usuario - ©1999 Programación Visual 4 La especificación del programa se realiza utilizando gráficos y layout bidimensionales –ej. Los sistemas que utilizan diagramas de transición de estados suelen utilizar una representación visual –ej. Sistemas basados en el flujo de datos Los iconos representan pasos de procesamiento, y el flujo transcurre a través de sus interconecciones ej. Labview, AVS  La utilización de un lenguaje visual parece ser más sencillo para programadores novatos  Los programas grandes pueden producir especificaciones muy complejas e incomprensibles

Construcción de Interfaces a Usuario - ©1999 Programación Visual

Construcción de Interfaces a Usuario - ©1999 Programación Visual

Construcción de Interfaces a Usuario - ©1999 Frameworks de Aplicación 4 Diseño abstracto de una aplicación, que puede ser instanciado para cada aplicación particular –Guía a los programadores en la construcción de aplicaciones –Provee clases básicas, a partir de las cuales se desarrollan las aplicaciones –ej. MacApp Desarrollado para programadores Apple, tratando de facilitar la utilización del Macintosh Toolbox (y tuvo éxito) Implementado en Object Pascal Se proveen clases implementando las partes principales de una aplicación (ventanas principales, comandos, etc.) El programador especializa estas clases para proveer los detalles específicos de la aplicación –ej. Unidraw. Especializado para editores gráficos Utiliza C++ e Interviews –ej. MFC

Construcción de Interfaces a Usuario - ©1999 MacApp

Construcción de Interfaces a Usuario - ©1999 Herramientas basadas en modelos 4 El programador describe la operación del SI o la IU en un lenguaje de especificación (el “modelo”) –El modelo es una descripción de alto nivel –Generalmente, tiene una forma declarativa 4 El sistema crea automáticamente la interfaz –Utiliza un toolkit de bajo nivel para los widgets 4 Objetivo: –Describir la interfaz en un alto nivel es más sencillo que escribir código para un toolkit –La generación automática de la interfaz puede producir mejores IU que las desarrolladas por programadores –Permitir la creación dinámica de objetos

Construcción de Interfaces a Usuario - ©1999 Herramientas basadas en modelos 4 Pueden proveerse herramientas que “razonen”sobre el modelo para producir distintos aspectos de la IU –Generación automática de ayudas, undo, etc. –Puede transformarse una interfaz en otra distinta, pero con una funcionalidad equivalente –Verificación de principios de diseño (consistencia, completitud, etc.) –Análisis automático de la calidad (ej. modelo NGOMS) 4 Evolución del enfoque declarativo –El sistema posee conocimiento o inteligencia para aliviar el trabajo del programador 4 Tipos –Constructores de cajas de diálogo: Mickey, DON, Jade,... y muchos más –Representaciones completas de la interfaz: ITS, UIDE, Humanoid, MasterMind.

Construcción de Interfaces a Usuario - ©1999 Herramientas basadas en modelos 4 Este enfoque está aún a nivel de investigación  Alto potencial y futuro  Los modelos son bastante disímiles en los sistemas actuales  Las UI generadas actualmente no son muy buenas  Los lenguajes de especificación suelen ser dificiles de usar y aprender –Existe bastante investigación para tratar de ampliar el conjunto de IU generables con este enfoque, y para facilitar el uso de estas herramientas.

Construcción de Interfaces a Usuario - ©1999 Constructores de Cajas de diálogo 4 Parte más sencilla para generar de la IU –Dada una lista de los contenidos, automáticamente: –1. Seleccionar los widgets Tipo del input deseado –string = text input field –numero = slider –uno de muchos = radio button u opciones pop-up –muchos de muchos = check boxes o menúes múltiples –comandos = menúes –2. Disponer espacialmente los widgets Utilizando principios para diseñar el look & feel –Donde colocar el botón OK? –Que comandos en qué menúes? Basado en criterios de diseño gráfico –3. Colocar los valores para las variables

Construcción de Interfaces a Usuario - ©1999 Jade –Dada una especificación textual de los contenidos (y tipos), crea una caja de diálogo Especifica separadamente el look & feel Define la correspondencia entre tipos y selecciones de widgets –Utiliza reglas de diseño para un buen layout –Puede utilizarse un editor gráfico posterior para mejorar la presentación –Permite la creación dinámica de cajas de diálogo, cuando un programa genera y/o modifica la lista de contenidos –Pueden especificarse restricciones para establecer dependencias entre los widgets  Evita al programador preocuparse acerca de los aspectos de layout  La especificación tiene una sintaxis rígida

Construcción de Interfaces a Usuario - ©1999 Jade

Construcción de Interfaces a Usuario - ©1999 Jade

Construcción de Interfaces a Usuario - ©1999 DON –Provee al diseñador guías acerca del tamaño, layout, selección de widgets, etc. –El diseñador puede especificar preferencias –Genera múltiples diseños –Analiza distintos diseños alternativos, en base a: Balance de los widgets componentes Agrupamiento de items relacionados Uso efectivo del espacio otros... –Utiliza métricas para comparar los diseños

Construcción de Interfaces a Usuario - ©1999 DON

Construcción de Interfaces a Usuario - ©1999 Descripción completa de la IU 4 El modelo debe contener una especificación completa de la interfaz –Utilizando un lenguaje especial –Puede describir Tareas Funcionalidad de la aplicación Presentación y comportamiento Diálogo Características de la plataforma Características del ambiente de trabajo Preferencias del usuario

Construcción de Interfaces a Usuario - ©1999 User Interface Design Environment (UIDE) 4 El programador define una “base de conocimiento”, describiendo la semántica de la aplicación –Objetos (jerarquía clases/subclases) –Acciones Incluyen pre y post condiciones, utilizadas por el sistema para tratar de generar la interfaz automáticamente 4 Provee: –Transformaciones entre distintas interfaz (semanticamente equivalentes) –Genera automáticamente las ayudas, con animaciones como tutoriales –Intenta determinar las presentaciones y secuencia de acciones

Construcción de Interfaces a Usuario - ©1999 Humanoid 4 Componentes del modelo: –Aplicación –Presentación –Manipulación –Secuenciamiento –Efectos laterales 4 Provee: –Selección automática de las técnicas de interacción, utilizando templates –Generación de ayudas (‘balloon’) –El lenguaje de modelado incluye construcciones para abstracción, composición, recursión, iteración y condicionales –Un conjunto de herramientas interactivas para ayudar al diseñador a especificar el modelo –Determinación de presentaciones, secuenciamiento, etc.

Construcción de Interfaces a Usuario - ©1999 Humanoid

Construcción de Interfaces a Usuario - ©1999 Especificación Gráfica Directa 4 Permiten definir la IU (al menos parcialmente), colocando objetos en la pantalla con un dispositivo de apuntamiento –Motivación: la presentación gráfica de la IU es muy importante en las interfaces gráficas –Una herramienta gráfica parece ser la forma más conveniente para hacerlo  Enfoque sencillo para el diseñador  Pueden ser utilizados por no programadores  El diseño de la interfaz puede ser realizado por especialistas, sin conocimiento de programación

Construcción de Interfaces a Usuario - ©1999 Herramientas de prototipación 4 Intentan que el diseñador pueda esquematizar algunos ejemplos de la apariencia deseada para la presentación. –Objetivo: visualizar rápidamente el diseño de la interfaz También pueden mostrar el secuenciamiento de la interfaz –Generalmente, estas herramientas no pueden ser usadas para crear la IU real, solamente se muestran algunos aspectos de su presentación Muchas partes de la interfaz no son operables, y otras son solamente imágenes estáticas (ej. widgets) Las UI deben ser recodificadas luego de la prototipación –Existe el riesgo de que los codificadores de la IU ignoren la prototipación

Construcción de Interfaces a Usuario - ©1999 Herramientas de prototipación 4 Forma de uso general: –El diseñador estudia diferentes diseños de la interfaz, y luego se implementa el diseño final utilizando un sistema diferente. –La mayoría de los sistemas de prototipación pueden ser utilizados sin programación Son aptos para diseñadores gráficos u otros especialistas 4 Sistemas –ej. Demo Permite al diseñador crear pantallas ejemplo, compuestas por caracteres y caracteres gráficos. También se especifican las acciones que determinan las transiciones entre ventanas Es dificil definir otros comportamientos

Construcción de Interfaces a Usuario - ©1999 Herramientas de prototipación 4 ej. Silk –Trabajo actual: proveer sketches de la IU, y luego transformarlos en widgets reales.

Construcción de Interfaces a Usuario - ©1999 ‘Cards’ 4 Muchos programas gráficos están limitados a IU que pueden ser presentadas como una secuencia de páginas generalmente estáticas –‘frames’, ‘cards’, ‘forms’ –ej. HyperCard (Apple) Ejemplo más conocido, basado en tarjetas Existen varios programas similares: GUIDE, Spinnaker Plus, ToolBook. El diseñador puede crear tarjetas conteniendo distintos tipos de campos, junto con varias decoraciones gráficas. Los botones pueden causar transiciones a otras tarjetas Estos programas proveen un lenguaje de scripting (ej. HyperTalk), el cual es un lenguaje de eventos

Construcción de Interfaces a Usuario - ©1999 ‘Interface Builders’ 4 Permiten crear cajas de diálogo, menúes y ventanas que forman parte de una interfaz mayor. –El diseñador selecciona un widget de una biblioteca con widgets predefinidos, colocándolo en la pantalla con el mouse –Pueden colocarse otras propiedades del widget por medio de planillas de colocación de propiedades (‘property sheet’) 4 En algunas ocasiones, se provee soporte para el secuenciamiento de acciones –ej. apertura de una caja de diálogo cuando se presiona un botón

Construcción de Interfaces a Usuario - ©1999 ‘Interface Builders’

Construcción de Interfaces a Usuario - ©1999 ‘Interface Builders’

Construcción de Interfaces a Usuario - ©1999 ‘Interface Builders’ 4 Existen muchos interface builders comerciales –ej. NeXT Interface Builder, WindowsMAKER, UIMX, devGuide 4 Muchas de las herramientas de construcción de interfaces también incluyen interface builders 4 Enfoques: –Generar templates de código C, que pueden ser compilados y/o vinculados con el código de la aplicación. –Generar una descripción de la IU en un lenguaje que puede ser interpretado en tiempo de ejecución ej. UIMX genera UIL –Si el programador modifica el código generado, la herramienta generalmente no puede ser utilizada para posteriores modificaciones de la IU

Construcción de Interfaces a Usuario - ©1999 ‘Interface Builders’  Fáciles de usar  Proveen poca asistencia para crear buenas IU, ya que proporcionan demasiada libertad al diseñador  No proveen soporte para especificar el contenido de las áreas de dibujo (ej. editores)  No suelen proveer soporte para manejar widgets que cambian dinámicamente

Construcción de Interfaces a Usuario - ©1999 Editores ‘By demonstration’ 4 El diseñador puede especificar sólo un ejemplo de la presentación deseada, que será modificada durante la ejecución –‘Demonstrational programming’ –Se opera sobre objetos-ejemplo, que representan objetos que serán creados en tiempo de ejecución ej. el sistema debería hallar que el tamaño de las cajas depende de los rótulos tipeados por el operador ej. colocar los objetos en su posición aproximada, y que el sistema deduzca las restricciones entre ellos. –En general, estos sistemas permiten al operador operar sobre ejemplos, y luego generalizar las acciones para producir un procedimiento general o un prototipo –La tarea de generalización es muy dificil Estas herramientas se encuentran aún en etapa de investigación

Construcción de Interfaces a Usuario - ©1999 Editores ‘By demonstration’ –ej. Peridot Permite la creación de nuevos widgets El diseñador maneja primitivas como rectangulos, circulos, texto, y líneas. El sistema generaliza las acciones del diseñador para crear procedimientos OO parametrizados, similares a los provistos por los toolkits. Puede ser utilizado por no programadores

Construcción de Interfaces a Usuario - ©1999 Comparación de herramientas

Construcción de Interfaces a Usuario - ©1999 Evaluación de herramientas de construcción de UI 4 Dimensiones de evaluación: –‘Depth’: que porcentaje de la IU es cubierto por la herramienta? –‘Breadth’: cuantos estilos de IU son soportados? –Portabilidad: puede ejecutarse la IU generada en diferentes plataformas? –Facilidad de uso de herramientas: es muy dificil utilizar la herramienta? –Eficiencia para los diseñadores: cuanto tiempo lleva construir una interfaz? –Calidad de las IU producidas: genera la herramienta IU de calidad? –Perfomance de la interfaz resultante: la interfaz generada se ejecuta rápidamente? –Precio: costo de la herramienta –Robustez y soporte: soporte técnico provisto por la herramienta

Construcción de Interfaces a Usuario - ©1999