Tabla de Contenidos

Introduccion

El presente documento deberá ser interpretado como el estándar a nivel de diseño de interfaces de usuario en el momento de construir la aplicación, de modo tal que las interfaces con el usuario sean homogéneas.

El diseño de las interfaces estará basado en la utilización del Toolkit Gtk+ (http://www.gtk.org/) y todas las ventanas deberán cumplir con las Human Interface Guidelines (version 2.0) del proyecto Gnome.

Un resumen de estas especificaciones se puede encontrar al final de este documento.

La especificacion esta pensada para utilizar el toolkit Gtk . Dos de las caracteristicas mas importanes de este toolkit es que soporta nativamente i18n y l10n, y por otro lado soporta temas. Es por eso, que a lo largo del documento es posible que vea textos de botones en ingles, iconos distintos para el mismo boton y cambios que, a primera vista, parecen cosas diferentes, cuando en realidad es el mismo ejemplo solo corriendo en entornos diferentes.

Esto se ha considerado hacerlo de esta forma, para mostrar distintas variantes a fin de familiarizar al desarrollador con la herramienta elejida.

Aspectos Generales

Si bien existirán diversas pantallas en toda la aplicación para los distintos circuitos de la misma, el formato de la interfaz debe ser homogéneo para toda la aplicación. El propósito de esta sección del documento es de definir y especificar esa homogeneidad.

Todas las ventanas deberán ajustar su diseño a una ventana de 800x600 pixels (Considerar 720x600 descartando posibles paneles o barras del sistema operativo). Cualquier cambio en el tamaño de la pantalla deberá reaplicarse relativo al mismo y reformular esta documentación.

Alertas

Objetivos

Informar al usuario posibles consecuencias de una accion o finalizacion de procesos.

Especificacion

Las alertas deberan ser usadas en aquellos lugares donde los CUSO o el SISTEMA requiran informar algo al usuario. Por ejemplo : Perdida de conexion con la base de datos; Confirmacion antes de eliminar; Notificacion de proceso exito en Pedido de Autorizacion Manual

Funcionamiento

Los mensajes de alerta se mostrarán utilizando un dialogo de mensaje modal, con un ícono descrptivo al tipo de error y un texto indicando el problema. Con esto lo que se intenta expresar, es que debe tener significancia instantánea ante los ojos del usuario, con lo cual se deben ubicar cerca de donde se produjo una anomalía. A modo de ejemplo, un formato erróneo introducido en una caja de texto podría llevar a un error cuando se realice luego una transacción de datos, con lo cual el mensaje de alerta debe ir por debajo de la caja de texto.

Ejemplos

La alerta de tipo Error sera emitida cuando se de una condicion irrecuperable, como se la perdida de coexion con la base de datos. Contara solamente con un boton Cerrar y debera abortar la aplicacion en caso de ser necesario.

Este dialogo informa de una operacion terminada exitosamente. Por ejemplo, al cargar un nuevo registro en un ABM, con un mensage que diga “La operacion fue realizada correctamente”.

Las preguntas deberan ser usadas en casos donde el usuario pueda cometer errores, pero sin afectar el funcionamiento normal de la aplicacion. Por ejemplo, un dialogo que al cancelar una accion le pregunte si esta seguro de querer cancelar un ABM.

Este diagogo es parecido al anterior, solo de que debe ser usado cuando el resultado de la operacion sea critico o no reversible. Por ejemplo, antes de eliminar un registro o dar de baja un afiliado, deberia aparecer un dialogo de confirmacion de Advertencia. Se debera informar las posibles consecuencas de la accion.

Ventana Principal

Objetivos

Centralizar el acceso a las distintas funcionalidades del sistema y proveer de la interfaz de login del sistema.

Especificacion

No correspode

Funcionamiento

La ventana principal tendrá una barra de menu en la parte superior y una barra de estado en la parte inferior. En el centro se encontrará el nombre de a aplicación justo con los datos de la filial de la obra social, su número de cuit, dirección y todos los datos con los que se identifica el usuario.

Ventanas de Consulta

Objetivo

Permitir al usuario consulta de datos, ya sea para informar a terceros como para consulta interna.

Especificacion

Todos los casos de uso Consultar , como ser Consultar Afiliado, Consultar Planes, etc

Funcionamiento

Todas la ventanas que impliquen consultas estarán organizadas como se especifica a continuación.

En la parte superior izquierda se mostrarán los criterios de búsqueda posibles, alineados en un contenedor de tipo tabla. El botón de buscar será definido por un StockButton de tipo "Buscar", ubicado en la última fila alineado a la derecha.

Los criterios de busqueda deberan ser tomados siguiendo las siguientes pautas :

Deberan figurar al menos los campos claves unicos de los objetos (como ser Tipo y Numero de Documento para Afiliados)

Deberan estar los campos triviales al momento de requerir informacion, como ser Apellido y Nombre para el mismo caso de Afiliado. Direccion es un claro ejemplo de un filtro que no es util y no deberia encontrarse

Claves foráneas. Los datos principales de aquellas relaciones de herencia o composición que la clase de dominio tenga con alguna otra.

Debajo de este se encontrará una lista (representada por un control TreeView con modelo ListStore) donde se mostrán los registros que complan con los criterios de la búsqueda. En la parte inferior se encontrará un botón con el texto "Ver" sin icono.

Las columnas a agregar en la lista deberan ser :

Todos los datos relacionados con los criterios de busqueda

Aquellos datos de mayor importancia del dominio

Si la busqueda retorna mas de N elemengos (siendo N un valor configurable por el administrador del sistema) se debera avisar al usuario que su busqueda a arrojado demasiados elementos y si desea mostrarlos todos o acotar la busqueda introduciendo nuevos criterios. Esto es a fin de maximizar la performance y minimizar el consumo de ancho de banda.

En la parte derecha del layout se encontrarán los datos a mostrar, según correspondda. Si la ventana lo requiere, pueden existir botones en la parte inferior de esta área para acceder a datos extra o secundarios.

La ventana donde se muestran estos datos deberá ser un diálogo modal, con un botón de cerrar (StockButton CLOSE) en la parte inferior dechecha del mismo.

Ejemplo

Diagrama de Transicion de Estados

Ventanas ABM

Estas ventanas serán para carga de datos. Existen diferentes variantes que iremos especificando a lo largo de la sección.

ABM Básico

Objetivo

Permitir ingreso de datos para clases simples del dominio s.

Especificacion

Algunas clases del dominio que encajan en esta categoria:

Categorias

Cap

Prestacion

Funcionamiento

Presentan típicamente solo campos de caja de entrada, listas de seleccion, radio buttons y checkboxes. Los campos a mostrar seran aquellas propiedades del objeto del dominio que sean modificables por el usuario y no requieran de un proceso a parte (como las fechas de baja de algunos elementos).

El diálogo de carga será modal, con botones de Aceptar y Cargar ubicados como se ilustra. Dentro del mismo se debera encontrar una tabla, con separacion de columnas y filas seteada en 8 pixels, en 2 columnas. La columna de la izquierda contendra etiquetas identificadores del campo a modificar, con el texto alineado a la izquiera. En la columna de la derecha se debera poner el objeto para el ingreso del dato.

Para el caso de Modificacion, si algun campo no puede ser modificado, debera desactivarse dicho campo para modificacion solamente, pero debera ser mostrado su valor actual.

ABM Complejos

Objetivos

Existen diversos casos donde la ventana de carga de datos debe ser mas elaborada, permitiendo cargar incluso relaciones entre distintas clases del dominio. Veremos a continuacion algunos aspectos a tener en cuenta para la creacion de las pantallas.

Especificacion

Otras ventanas que encajan en esta categoria

Alta Autorizacion Manual

ABM Promotor

ABM Afiliado

ABM Plan

Funcionamiento

Como ejemplo usaremos la clase Solicitante. Si observamos el diagrama de clases, el solicitante es una persona (hay una herencia) y su vez tiene una composicion con una Direccion. Para crear la ventana, se debera utilizar un frame por cada relacion (herencia o composicion), debidamente identificada con un nombre representativo de la composicion.

En este ejemplo, la ventana tendra 3 frames:

Datos Personales

Direccion

Solicitud

Dentro de cada frame, debera existir una matriz cuyos elementos sigan las reglas especificadas en el punto ABM Basico, especificado anteriormente.

Siguiendo este esquema, la ventana de Alta de Afiliado sera igual a la mostrada en el Ejemplo 1, pero en lugar de contener la seccion Solicitud, tendra una seccion Plan, donde se detalle el plan actual. Asi mismo, tendra otra seccion con botones “Consultar Historial de Planes” y “Consultar Autorizaciones” donde se podra observar los planes a los que ha pertenecido (o pertenece) y las autorizaciones aprobadas o rechazadas del Afiliado.

La ventana de AMB de Promotor sera igual a la del Ejemplo 1, salvo que no contendra la seccion Solicitud. Los Solicitantes asociados no se muestran aqui ya que para eso existe la vista Emitir Hoja de Ruta.

Las ventanas de ABM de planes se ejemplifica en el Ejemplo 2 con su Diagrama de Transicion de Estados correspondiente.

Ejemplo 1

ABM de Relaciones

Objetivo

Asociar datos entre dos entidades del dominio

Especificacion

Funcionamiento

Este tipo de ventanas esta pensado para, por ejemplo, relacionar un Promotor con un Solicitante, en Emitir Hoja de Ruta.

Luego de seleccionar de una lista de Promotores un elemento, se obtienen los Solicitantes libre y los asignados a dicho promotor. Los libres deben ser cargados en una lista de tipo TreeView y los asignados en una lista a la derecha. Entre ambas listas deberan encontrarse 2 stock button : Agregar y Borrar, como se ve en el ejemplo.

El boton Agregar debera pasar un elemento de la lista izquierda a la de la derecha y el Borrar en sentido opuesto. Los cambios deberan ser registrado solo cuando el boton Aceptar sea presionado

Ejemplo

Pedido de Autorización Manual

Objetivos

Registrar un pedido de Autorizacion Manual

Especificacion

Caso de Uso : Pedido de Autorizacion Manual

Funcionamiento

Los botones marcados como "..." son de búsqueda. En el caso de que el operador no recuerde los códigos, dispondrá de la ventana de búsqueda para encontrar el código por varios criterios (Ver la sección más adelante sobre Ventanas de Búsqueda).

La ventana además presenta 2 posibles alertas, que pueden o no ser tomadas en cuenta por el Operador que cargue la Autorización. Una es acerca del estado de cuenta y otra sobre el límite de prestaciones anual del afiliado.

Ejemplo

Pantallas de Búsqueda

Objetivo

Ayudar al usuario a encontrar codigos referidos en distintos casos de uso

Especificacion

No corresponden a ningun caso de uso particular.

Funcionamiento

Estas pantallas son auxiliares y no pertenecen a un caso de uso. La idea es utilizar estas pantallas de manera reutiluzable en donde sean necesarias búsquedas para ayudar al usuario a encontrar códigos necesarios para otras pantallas.

El botón "Seleccionar" tendrá como acción cerrar el diálogo y completar el campo correspondiente de la ventana que lo llamó.

Los criterios de búsqueda se seleccionarán en cada caso, atendiendo a los campos más representativos del registro.

Ejemplo

Mantener Planes

Este caso será utilizado para utilizado para ejemplificar como se realizan las vistas de todos los casos “Mantener”.

Objetivos

Agregar, Modificar o Eliminar datos en tablas.

Especificacion

Caso de Uso : Mantener Planes, Mantener Caps, Mantener Afiliados, Mantener Prestaciones, etc.

Funcionamiento

Cada caso de uso comienza mostrando una ventana como la siguiente :

La ventana presenta una lista (TreeView) con un modelo ListStore y 3 botones : Agregar , Propiedades y Borrar.

En la lista deberán aparecer los datos principales de la clase del dominio.

Opcionalmente, puede incluirse antes de la lista un sección de búsqueda, para los casos donde la cantidad de elementos pueda llegar a ser grande. En recomendable utilizar este ítem en Mantener Planes, por ejemplo.

Los 3 botones ejecutarán como acción la ventana de “Alta”. Para el caso de Agregar, todos sus campos estarán vacíos. En el caso de modificación, solo deberán estar sensibles aquellos que puedan ser modificados dese este caso de uso.

Para el caso de borrar solo se mostrarán los campos sin sensibilidad (es decir, no modificables) para información del usuario antes de realizar la operación.

Para el casos complejos como Mantener Afiliados o Mantener Planes, la venta tendrá a su vez operaciones de ABM sobre los campos que lo requieran, para el manejo de las colecciones nacidas en base a composiciones con otras clases del dominio. Como se ejemplifica en la ventana de más arriba.

Las ventanas de ABM de las relaciones son todas ABM Básicos como ya se habló en los puntos anteriores.

Un ejemplo para el caso de Mantener Planes, es la alta de una Cobertura :

Actualizar Autorizacion Manual

Esta ventana es tal vez una de las más complejas e importantes, es por eso que haremos un alto para mostrar y definir como debe funcionar.

Objetivos

Aprobar o Rechazar las autorizaciones manuales

Especificacion

Caso de Uso : Actualizar Autorización Manual.

Funcionamiento

Al autitor médico se le presenta la siguiente pantalla :

Lo que se muestra en la imágen es solo el esqueleto. La lista presentará por cada fila todas las autorizaciones pendientes de aprobación o rechazo, con las siguientes columnas :

Código de autorización

Fecha Solicitud

Tipo y número de documento

Apellido del Afiliado

Observaciones de la Solicitud

Las filas deberán estar ordenadas inicialmente opr Fecha de Solicitud, pero clickeando sobre los títulas de las columnas el Auditor Médito podrá cambiar este orden.

Al seleccionar una autorización y presionar el botón “Revisar” se despliegarpa la siguiente ventana :

La ventana está dividida en 3 secciones diferentes, cada una brindando información hacerca de diferentes aspecto que el auditor utilizará para evaluar la resolución final.

Las secciones son bastante claras y no necesitan mucha explicación, solo haremos algunas aclaraciones de alguna de ellas.

Estado de cuenta : El auditor médico solo requiere saber si el afiliado es o no moroso, por eso solo muestra el mensaje simple. El valor entre corchetes rectos indica que esa palabra puede o no aparecer.

Plan : Inicialmente el usuario recibe un mensaje indicando si la prestación está o no cubierta en el plan actual del cliente. Se puede ejecutar una acción de consulta sobre el Plan presionando el botón “Consultar Plan” (ver la sección de ventanas Auxiliares detallada más arriba para el formato de esta ventana).

Consumo de esta Prestación : Se informa cuantas prestaciones se ha realizado en este año el Afiliado (para la prestación pedida) y el límite anual indicado en la Cobertura del Plan vigente. El auditor puede Consultar todos los consumos de esta prestación presionando “Consultar Consumos” (solo se verán los consumos relacionados con la prestación en cuestión, no todos los consumos).

Consultar Autorización

Objetivos

Ver los datos principales de una autorización en caso de necesidad interna o consulta externa por parte de Afiliados o Prestadores.

Especificacion

Caso de Uso : Consultar Autorización

Funcionamiento

Esta ventana es de especial importancia explicar su funcionamiento ya que rompe con los esquemas mensionados anteriomentes.

El principal motivo de esto es la gran cantidad de información que maneja, tanto a nivel relaciones como en volumen de datos.

No sería óptimo ni funcional utilizar listas como en ejemplos anteriores ya que solo harían inusable la aplicación desde todo punto de vista.

La ventana estará organizada de la siguiente manera :

El funcionamiento básico está definido en el caso de uso correspondiente.

Por si el programador no está familiarizado con la notación de expresiones regulares, aclararemos que las equitetas que contiene valores como “[Elemento1|Elemento2]” significa que esa etiqueda deberá tomar uno de esos posibles valores como texto.

Los botones de búsqueda disparan diálogos modales con ventanes de consulta (ver sección correspondiente más arriba) en el caso de búsqueda por Afiliado y Auditor médico, y diálogos de entrada de datos en el caso de búsquedas por código o fecha.

Los 4 botones ubicados abajo de la ventana son la barra de navegación. Ellos permiten desplazarse entre los diferentes registros que concuerdan con el criterios de búsqueda.

Por último, el botón “Cerrar”, cierra el diálogo.

http://developer.gnome.org/projects/gup/hig/

http://www.gtk.org

2005-06-21T11:02:09