Usabilidad. Entidades numerosas ¿cómo harían?

[Bauhaus1975]

Hola a todos, con este post pretendo aprender y dejar algunas explicaciones resultas de aquellos de vosotros que tenéis más experiencia o más creatividad.
Se trata de que deis vuestra opinión de cómo organizar formularios, métodos de funcionamientos (interfaces en definitiva) y podamos aprender o dejar plasmadas aquí algunas recomendaciones a la hora de diseñar funcionamientos más o menos habituales.

Primer caso: Cómo organizar el funcionamiento de un módulo o parte de programa que maneja entidades con muchos elementos, y necesitamos administrar con las funciones habituales de crear, editar, eliminar, buscar… El ejemplo más claro puede ser la parte de manejo de clientes de un programa, en el que puede haber cientos de elementos y necesitamos acceder de manera rápida y manejar fichas con numerosos campos.
¿Cómo organizarían el / los formulario/s, su funcionamiento etc?
¿Qué componentes usarían para facilitar las cosas en el caso que he descrito?

Espero que este tipo de debates aporten conocimiento y sean de provecho.
Gracias a todos.

[pvizcay]

En dicho caso yo tengo dos entidades básicas:

> una lista, donde se ven los elementos a trabajar en una grilla con sus datos más importantes (en tu caso los clientes) y donde tenes los comandos Agregar, Editar y Eliminar

> un editor donde ves el "detalle" de la entidad (el cual se abre al selecionar agregar y editar desde la lista) donde estan todos los campos del cliente (en el editor solo podes ver uno)

salu2

[Bauhaus1975]

Hola, y gracias por ser el primero en dar tu opinión. Ciertamente, como dices es cómo me parece más cómodo. Así tendríamos DOS Formularios que se abrirían modalmente (Listados y Ficha):

1. Formulario para listar los elementos (clientes) en un tipo de Grid, pienso que en este form debe incorporarse la funcionalidad para buscar por combinación de criterios (p.e. apellidos, DNI...), y/o búsquedas directas (p.e. últimos dados de alta etc.) También desde aquí debería poder enlazarse con la funcionalidad de nuevo, edición (al pulsar el elemento seleccionado), eliminar.

2. Formulario Ficha. Aquí estarían todos los datos o campos del cliente. Para dar de alta nuevo o modificar, según de la acción de la que vengamos. Si hay muchos datos se podría usar un PageControl para organizarlo mejor.

3. Podría existir un tercer formulario para búsquedas rápidas de algunos criterios, con idea de añadir esta funcionalidad cuando en otras partes del programa hay que añadir un cliente, así se podría seleccionar de este formulario. Si no hubiera muchos elementos, una lista con todo podría servir.

Ahora, con la cantidad de librerías de componentes que hay.. no sé si alguien tiene una idea mejor de organización.

[[Lepe]]

Aunque Microsoft desaconseja el uso de interfaz MDI, y salvando los errores conocidos, prefiero usar esta interfaz por tener todo recojido. Las ventanas modales, sólo las uso cuando no se puede continuar la aplicación porque necesita datos vitales.

1.Formulario para listar los elementos (clientes): No sé a que le llamas "enlazar con la opción de Nuevo/modificar/eliminar". Yo lo que hago es llamar a la ventana de cliente especificando el IDCliente. La ventana de "listar" no puede modificar ni eliminar, sólo llama a la ventana de clientes al hacer doble clic. (elimino duplicidad de código, y posibles efectos colaterales).

2. Formulario Ficha. (nada que comentar, concuerdo totalmente).

3. Búsquedas rápidas: Yo actualmente uso un Frame, contiene un grid con un Toolbar. Me permite explorar / localizar / imprimir cualquier elemento (cliente, factura, albaran, empresa) con sólo especificar un parámetro.

Para el tercer punto, uso una metodología estricta en mis tablas:
- Nombre de tabla: cliente, factura
- clave primaria: IDcliente, IDfactura

Este frame recibe el parámetro "nombre de tabla", si le paso
"cliente", crea la sql de búsqueda "SELECT * FROM CLIENTE WHERE CLIENTE LIKE '%' + edtBusqueda.text+ '%' + 'ORDER BY IDCLIENTE".

Al hacer doble clic en el grid, se abre su ventana propia (factura, cliente, etc), localizando el elemento.

Nota: En realidad no uso parámetros de tipo string, tengo declarado algo así:

Código Delphi [-]
unit global;

interface

type TVentana = (vCliente, vFactura, vAlbaran);

var VentanaDesc = array [TVentana] of string = ('cliente', 'factura', 'albaran');

function AbreVentana(tipo:TVentana; const ID:integer = 0):TBaseForm;

Aquí otro truco más, Tengo un Formulario Base del que heredan todas las ventanas con la propiedad ID:integer.

AbreVentana crea el tipo de ventana TFrmClientes y asigna el ID si es distinto de cero, después muestra la ventana en pantalla.

Saludos

[Bauhaus1975]

Hola

Empezado por Lepe

1.Formulario para listar los elementos (clientes): No sé a que le llamas "enlazar con la opción de Nuevo/modificar/eliminar".

Pues que desde donde se listan los elementos, encontramos botones o 'maneras' para desencadenar las acciones de Nuevo, modificar o eliminar. En los dos últimos casos previa selección del elemento (cliente), creo que igual que tú explicabas. Efectivamente, creo que lo mejor es que desde donde se listan los elementos no se puedan modificar.

Tu aportación sobre como organizar el código para búsquedas es interesante, aunque yo intento no tener funciones 'sueltas', sólo métodos de clase.

Para búsquedas rápidas propondría tener un formulario (clase heredada de TForm). En tiempo de ejecución añadiríamos un par de componentes para recibir parámetros (segun la entidad de la q se trate) y poder buscar con ellos. Y que éste formulario fuera capaz de devolver el (Id,nombre,..) al formulario que espera el dato. Haria falta para ello tener definido para cada entidad (cliente, factura etc) que parametros son necesarios para búsquedas rápidas.

[[Lepe]]

Empezado por Bauhaus1975

yo intento no tener funciones 'sueltas', sólo métodos de clase.

Entonces creas una clase llamada TVentanaAdmin con el método AbrirVentana (no tomes al pié de la letra lo que digo, ya que para que se entienda, omito algunos detalles de implementación ).

Empezado por Bauhaus1975

Haria falta para ello tener definido para cada entidad (cliente, factura etc) que parametros son necesarios para búsquedas rápidas.

Si sigues la metodología que digo, siempre buscarás por el campo principal de la tabla.

La ventana de búsqueda, puede tener un método llamado "LookUp" que hace un fieldbyname sobre el query de búsqueda, devolviendo un Variant por ejemplo. De esta forma la ventana de búsqueda puede devolver en tiempo de ejecución cualquier campo del dataset.

Otra forma de afrontar las búsquedas, es usando una tabla de configuración, por ejemplo la tabla config tiene dos campos de tipo string:

codigo                     Valor
-------------------------------------------------------------------------
ClientesSQL                select * from Vistaclientes where %s
ClientesFieldsSearch       Nombre,Dni,Domicilio,Telefono
FacturaSQL                 select * from Vistafacturas where %s order by numFactura
FacturaFieldsSearch        numFactura,Cliente,fecha

De esta forma una ventana general de búsqueda puede cargar dinámicamente los campos y SQLs, formateándolo sin importar en qué tabla está buscando. Como ves, uso una Vista (view si el motor lo soporta), donde se muestra el nombre del cliente que obviamente la tabla Facturas no lo tendrá (solo guardará el IDCliente).

"FieldsSearch" puede cargarse en el commaText de un ComboBox, por ejemplo, para que el usuario decida el campo de búsqueda y pueda añadir varios criterios a la vez.

Saludos

[Bauhaus1975]

Creo que te entiendo...
También las propiedades de búsqueda que comentas en vez de almacenarlas en una tabla podrían ser una propiedad de la clase TVentanaAdmin, ¿cierto?
Incluso podría ser una propiedad 'paramsBusqueda' que fuera una lista de TField, de esta manera al llamar a la ventana de búsqueda rápida con pasar la lista de parámetros y la tabla podría tanto añadir los componentes en tiempo de ejecución para realizar la búsqueda, como hacer la query una vez invocada la búsqueda. ¿y para retornar el valor seleccionado?

Otra cosa, antes mencionaste que no aconsejabas el uso de ShowModal, puedes dar tu consejo de como organizar / visualizar estos formularios que estamos comentado,
Gracias por tu aportación.

[[Lepe]]

Empezado por Bauhaus1975

Creo que te entiendo...
También las propiedades de búsqueda que comentas en vez de almacenarlas en una tabla podrían ser una propiedad de la clase TVentanaAdmin, ¿cierto?

Si lo guardas en TVentanaAdmin, esa configuración tendrás que guardarlo en algún sitio ¿un archivo ini?, ¿codificadas en delphi? Al tenerlo en una tabla de la base de datos, puedes usar IBExpert para añadir campos de búsqueda o eliminar alguno que se te haya pasado. También puedes modificar (con ciertas limitaciones) las sqls de búsqueda.

Empezado por Bauhaus1975

Incluso podría ser una propiedad 'paramsBusqueda' que fuera una lista de TField,

Eso te obliga de nuevo a tener los campos persistentes en delphi, es decir, no puedes utilizar la misma ventana para facturas y clientes, porque obviamente cada uno tendrá campos distintos.

La ventana de búsqueda rápida tendrá un TQuery, pero se configura todo en tiempo de ejecución, por eso tienes la libertad de usarlo con varias tablas sin problemas. Me explico mejor:

Tienes un Grid que va ligado a un TQuery, el TQuery no tiene nada en la propiedad SQL en tiempo de diseño. En ejecución, se le asigna la propiedad SQL a:

Código SQL [-]
select * from Clientes

Justo antes de abrirse el TQuery es cuando se rellena internamente con todos los campos que tenga la tabla clientes. Si en lugar de usar "clientes" usas "facturas" obviamente ahora el mismo TQuery tiene los campos de la tabla factura. Todo se hace en tiempo de ejecución.

Ahora puedes hacer:

Código Delphi [-]

function TFrame1.ObtenerValorDeCampo(NombreCampo:string):string;
begin 
  if query1.Active then
    Result := query1.Fieldbyname(nombreCampo).AsString;
end;

Que podrás llamar con result := ObtenerValorDeCampo('Cliente')

Empezado por Bauhaus1975

Otra cosa, antes mencionaste que no aconsejabas el uso de ShowModal,

Este tema da para un hilo completo .

Personalmente, para programas de facturación, me gusta una interfaz MDI (Multiple Document Interface), por ello todas las ventanas de clientes, facturas, etc, se abren dentro de la ventana principal, que tiene un menú y un toolbar. Como el usuario puede abrir varias ventanas al mismo tiempo, que él mismo se organice . Es más o menos este ejemplo (en el hilo completo puedes ver muchos ejemplos de los foristas).

La ventana de búsqueda rápida, sí es una buena candidata para ser modal, ya que necesita que el usuario de doble clic en un resultado para que la ventana de clientes muestre todos los datos, dicho de otra forma: Una ventana necesita de información proporcionada por otra para continuar, siempre que se cumple esa regla, usaría una ventana modal.

Por contra, la ventana de búsqueda normal (la que permite búsquedas avanzadas) no la hago modal, puede necesitar abrir la ventana de facturas para ver una fecha (por ejemplo).

No he diseñado aplicaciones SDI (sólo pequeñas utilidades con 2 o 3 ventanas a lo sumo) que son fáciles de administrar.

Saludos

[Bauhaus1975]

Mentalmente me había imaginado una clase padre, abstracta que defina propiedades comunes y métodos comunes. Luego cada tipo de formulario particular (clase que herede) podría contener su propia información de configuracion, como parámetros para busqueda rápida, tabla en la que están los datos etc. Aunque también se pueden tener en base de datos como dices.

Sobre MIDI / modal, yo tengo cierta tendencia al uso de ventanas modales porque tengo poca experiencia con Delphi, además si se pueden tener varias ventanas abiertas se pueden realizar modificaciones que impliquen refrescar datos o aplicar cambios en otras ventanas. Esto me complica bastante el funcionamiento.

Echaremos un vistazo al hilo que aportas. Gracias.

Saludos.

[[Lepe]]

Bueno, realmente no sé lo que necesitas y cuan complejo son las búsquedas a realizar. sea como fuere, solo te digo: KISS.

Keep It Simple Stupid . Es una filosofía de diseño bastante antigua; aunque la tarea a realizar sea compleja, ¡hazlo simple!.

Para lo de refrescar datos, piensa en un método genérico de tu Clase Base "RefrescarDatos" o "ReloadConfig", las clases hijas se encargan de cerrar los datasets y abrirlos de nuevo o de cargar de nuevo la configuración. Al estar en la clase padre, puedes hacer algo como:

Código Delphi [-]
for i:= 0 to screen.count -1 do
  if Screen.Forms[i] is TClaseBase then
   begin
    TClaseBase(Forms[i]).RefrescarDatos;
    TClaseBase(Forms[i]).ReloadConfig;
   end;

Saludos

[[Delphius]]

Desde hace unos días me tiene picando tu duda, primeramente estaba comprendiendo el tema desde un punto estético de las interfaces.

No se si sirve de algo, pero en cuanto a estética, (algo que en ocasiones no se lo toma en cuenta, y en otras veces se exagera) tal vez te sirve lo que se estuvo diciendo en este hilo hace un tiempo. A modo de complemento a lo que se ha estado diciendo aqui.

Recuerdo que Mamx en una ocasión me recomendó este sitio. Allí encontré unos artículos que hablan sobre el aspecto visual.

Saludos,

[Bauhaus1975]

Hola, tu aportación suma un poco más, gracias.
Mi intención en el hilo era hacer un análisis sobre cómo organizar los elementos: ventanas, elementos y cualquier cosa que comunique con el usuario para el caso planteado. El diseño sería otra capa abstracta del sistema (por encima de la que menciono); ni más ni menos importante. Piensa que lo que busco puede describirse sin ningún aspecto gráfico, incluso, imagina que la pregunta podría ser independiente del lenguaje, ahora que en programación web tenemos AJAX las posibilidades nos acercan más a aplicaciones escritorio tipo windows, puedes por tanto imaginar que la pregunta de "Usabilidad ¿Cómo organizar la interfaz para la gestión de entidades con muchos elementos?", podía haber sido planteada en un foro de AJAX... o bien, imagina representar el diseño funcional con componentes Delphi sin tocar propiedades gráficas de los componentes.
Siendo mi intención que esta sea la primera de una serie de 'hilos sobre usabilidad'.

De momento, la mayoria de 'los encuestados' organizariamos en dos formularios, uno para buscar los elementos y otro para introducir los datos de la ficha, (desaconsejando MIDI). También se ha comentado incluir la creación de un pequeño formulario genérico para búsquedas rápidas, a llamar desde otros formularios.

La idea de iniciar esta consulta me ha venido porque tengo poca experiencia en Delphi, vengo de desarrollo web, y quería ver que ideas tenía la gente ahora que con Delphi tenemos más posibilidades funcionales. Espero haber perfilado un poco más la idea del hilo, aunque insisto, todo con lo que habéis contribuido ha sumado y ayudado a tener más conocimiento (al menos para mí). Esperemos que la gente siga compartiendo sus ideas de organización.
Saludos.

[Bauhaus1975]

Se me coló un error...

Empezado por Bauhaus1975

De momento, la mayoria de 'los encuestados' organizariamos en dos formularios, uno para buscar los elementos y otro para introducir los datos de la ficha, (desaconsejando MIDI).

Quería decir: que se había desaconsejado el uso de ventanas modales, sólo en los casos donde sea estrictamente necesario obtener una respuesta del usuario.

[[Delphius]]

Empezado por Bauhaus1975

Hola, tu aportación suma un poco más, gracias.
Mi intención en el hilo era hacer un análisis sobre cómo organizar los elementos: ventanas, elementos y cualquier cosa que comunique con el usuario para el caso planteado. El diseño sería otra capa abstracta del sistema (por encima de la que menciono); ni más ni menos importante. Piensa que lo que busco puede describirse sin ningún aspecto gráfico, incluso, imagina que la pregunta podría ser independiente del lenguaje, ahora que en programación web tenemos AJAX las posibilidades nos acercan más a aplicaciones escritorio tipo windows, puedes por tanto imaginar que la pregunta de "Usabilidad ¿Cómo organizar la interfaz para la gestión de entidades con muchos elementos?", podía haber sido planteada en un foro de AJAX... o bien, imagina representar el diseño funcional con componentes Delphi sin tocar propiedades gráficas de los componentes.
Siendo mi intención que esta sea la primera de una serie de 'hilos sobre usabilidad'.

De momento, la mayoria de 'los encuestados' organizariamos en dos formularios, uno para buscar los elementos y otro para introducir los datos de la ficha, (desaconsejando MIDI). También se ha comentado incluir la creación de un pequeño formulario genérico para búsquedas rápidas, a llamar desde otros formularios.

La idea de iniciar esta consulta me ha venido porque tengo poca experiencia en Delphi, vengo de desarrollo web, y quería ver que ideas tenía la gente ahora que con Delphi tenemos más posibilidades funcionales. Espero haber perfilado un poco más la idea del hilo, aunque insisto, todo con lo que habéis contribuido ha sumado y ayudado a tener más conocimiento (al menos para mí). Esperemos que la gente siga compartiendo sus ideas de organización.
Saludos.

A mi opinión eso es ya más una cuestión de organización y de como trabaja uno.
Muy cierto es que también depende de las necesidades, los requisitos, las restricciones a la que se ve sometido el sistema (e incluso el proyecto mismo), pero lo más importante pasa ya por saberse organizar, tanto en lo referente a la estructuración del código como del diseño de las interfaces.

En este punto, considero que lo mejor es tener los "planos" que tanto unos odian porque son una "pérdida de tiempo"

Empezado por Bauhaus1975

Se me coló un error...

Quería decir: que se había desaconsejado el uso de ventanas modales, sólo en los casos donde sea estrictamente necesario obtener una respuesta del usuario.

Bueno, eso es cierto, y por ello que existen las modales.
En fin vuelvo a lo dicho antes: esto pasa por saberse organizar y dar forma a los requerimientos. Nuestra experiencia acumulada a lo largo de los años deberían servir para determinar (o al menos predecir) lo más viable, económico y técnico-operativo posible.

Saludos,