Tabla de Contenidos

Introduccion	2

Aspectos Generales	2

Alertas	2

Objetivos	2

Especificacion	2

Funcionamiento	2

Ejemplos	3

Ventana Principal	3

Objetivos	3

Especificacion	3

Funcionamiento	3

Ventanas de Consulta	4

Objetivo	4

Especificacion	4

Funcionamiento	4

Ejemplo	5

Diagrama de Transicion de Estados	5

Ventanas ABM	5

ABM Básico	6

Objetivo	6

Especificacion	6

Funcionamiento	6

ABM Complejos	6

Objetivos	6

Especificacion	6

Funcionamiento	6

Ejemplo 1	7

ABM de Relaciones	7

Objetivo	7

Especificacion	8

Funcionamiento	8

Ejemplo	8

Pedido de Autorización Manual	8

Objetivos	8

Especificacion	8

Funcionamiento	8

Ejemplo	9

Pantallas de Búsqueda	9

Objetivo	9

Especificacion	9

Funcionamiento	9

Ejemplo	10

Mantener Planes	10

Objetivos	10

Especificacion	10

Funcionamiento	10

Actualizar Autorizacion Manual	12

Objetivos	12

Especificacion	12

Funcionamiento	12

Consultar Autorización	14

Objetivos	14

Especificacion	14

Funcionamiento	14

Anexo – HIG Gnome	15

Introducción

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 (versión 2.0) del proyecto Gnome.

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

La especificación esta pensada para utilizar el toolkit Gtk . Dos de las características mas importantes 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 inglés, iconos distintos para el mismo botón 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 elegida.

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á replicarse relativo al mismo y reformular esta documentación.

Alertas

Objetivos

Informar al usuario posibles consecuencias de una acción o finalización de procesos.

Especificacion

Las alertas deberán ser usadas en aquellos lugares donde los CUSO o el SISTEMA requieran informar algo al usuario. Por ejemplo : Perdida de conexión con la base de datos; Confirmación antes de eliminar; Notificación de proceso éxito en Pedido de Autorización Manual

Funcionamiento

Los mensajes de alerta se mostrarán utilizando un dialogo de mensaje modal, con un icono descriptivo 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 condición irrecuperable, como se la perdida de conexión con la base de datos. Contara solamente con un botón Cerrar y deberá abortar la aplicación en caso de ser necesario.

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

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

Este dialogo es parecido al anterior, solo de que debe ser usado cuando el resultado de la operación sea critico o no reversible. Por ejemplo, antes de eliminar un registro o dar de baja un afiliado, debería aparecer un dialogo de confirmación de Advertencia. Se deberá informar las posibles consecuencias de la acción.

Ventana Principal

Objetivos

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

Especificacion

No corresponde

Funcionamiento

La ventana principal tendrá una barra de menú 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 búsqueda deberán ser tomados siguiendo las siguientes pautas :

Deberán figurar al menos los campos claves únicos de los objetos (como ser Tipo y Numero de Documento para Afiliados)

Deberán estar los campos triviales al momento de requerir información, como ser Apellido y Nombre para el mismo caso de Afiliado. Dirección es un claro ejemplo de un filtro que no es útil y no debería 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 muestran los registros que cumplan 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 deberán ser :

Todos los datos relacionados con los criterios de búsqueda

Aquellos datos de mayor importancia del dominio

Si la búsqueda retorna mas de N elementos (siendo N un valor configurable por el administrador del sistema) se deberá avisar al usuario que su búsqueda a arrojado demasiados elementos y si desea mostrarlos todos o acotar la búsqueda 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 corresponda. 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 derecha 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.

Especificacion

Algunas clases del dominio que encajan en esta categoría:

Categorías

Cap

Prestación

Funcionamiento

Presentan típicamente solo campos de caja de entrada, listas de selecciona, radio buttons y checkboxes. Los campos a mostrar serán 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 deberá encontrar una tabla, con separación de columnas y filas seteada en 8 pixels, en 2 columnas. La columna de la izquierda contendrá etiquetas identificadores del campo a modificar, con el texto alineado a la izquierda. En la columna de la derecha se deberá poner el objeto para el ingreso del dato.

Para el caso de Modificación, si algún campo no puede ser modificado, deberá desactivarse dicho campo para modificación solamente, pero deberá 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 continuación algunos aspectos a tener en cuenta para la creación de las pantallas.

Especificacion

Otras ventanas que encajan en esta categoría

ABM Promotor

ABM Afiliado

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 composición con una Dirección. Para crear la ventana, se deberá utilizar un frame por cada relación (herencia o composición), debidamente identificada con un nombre representativo de la composición.

En este ejemplo, la ventana tendrá 3 frames:

Datos Personales

Dirección

Solicitud

Dentro de cada frame, deberá existir una matriz cuyos elementos sigan las reglas especificadas en el punto ABM Básico, 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 sección Solicitud, tendrá una sección Plan, donde se detalle el plan actual. Así mismo, tendrá otra sección con botones “Consultar Historial de Planes” y “Consultar Autorizaciones” donde se podrá 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 contendrá la sección Solicitud. Los Solicitantes asociados no se muestran aquí 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 Transición 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 deberán encontrarse 2 stock button : Agregar y Borrar, como se ve en el ejemplo.

El botón Agregar deberá pasar un elemento de la lista izquierda a la de la derecha y el Borrar en sentido opuesto. Los cambios deberán ser registrado solo cuando el botón Aceptar sea presionado

Ejemplo

Pedido de Autorización Manual

Objetivos

Registrar un pedido de Autorización Manual

Especificacion

Caso de Uso : Pedido de Autorización 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 códigos referidos en distintos casos de uso

Especificacion

No corresponden a ninguna 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 reutilizable 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 desee 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 auditor médico se le presenta la siguiente pantalla :

Lo que se muestra en la imagen 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 por Fecha de Solicitud, pero clickeando sobre los títulos de las columnas el Auditor Médico podrá cambiar este orden.

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

La ventana está dividida en 3 secciones diferentes, cada una brindando información acerca 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 mencionados anteriormente.

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 etiquetas que contiene valores como “[Elemento1|Elemento2]” significa que esa etiqueta deberá tomar uno de esos posibles valores como texto.

Los botones de búsqueda disparan diálogos modales con ventanas 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.

Anexo – HIG Gnome

Las Human Interface Guidelines del proyecto Gnome son el lineamiento básico que cualquier aplicación debe seguir si pretende integrarse con el desktop Gnome en GNU/Linux.

Fueron seleccionadas como el estándar a seguir ya que el target de la aplicación fue un desktop Gnome corriendo en cajas con GNU/Linux, creando una solución Open Source en su totalidad.

El documento completo consta de unas 160 páginas, y fue realizado tras varios estudios de usabilidad realizados por los laboratorios de Sun Microsystem en el año 2000 y es continuamente actualizado. La versión en que nos basaremos será la 2.0.

Este estándar define varios puntos a tener en cuenta :

Principios de usabilidad

Integración con el Desktop

Ventanas

Menús

Toolbars

Controles (entrada de texto, listas, etc)

Feedback

Diseño visual

Íconos

Como puntos más destacados. Como nos hemos limitado a utilizar la mayoría de los controles e iconos estándar, varias de las secciones anteriores no nos son de importancia, por lo que solo resumiremos algunos conceptos importantes para entender el armado de las ventanas.

Nos centraremos en la parte de diseño visual, ya que es la más importante en nuestro caso.

Como primer punto, veamos la diferencia entre las siguientes imágenes :

Como puede observarse en el caso de la derecha, la separación en secciones utilizando un indentado proporciona una mayor claridad de los datos agrupados.

Las separaciones de los distintos componentes, bordes y alienaciones se pueden resumir en el siguiente ejemplo :

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

http://www.gtk.org

2005-06-21T11:02:09