Diseño de una cinta fluida para una aplicación CRUD
Estoy trabajando en el diseño de un UX de estilo Fluent ("Ribbon") para una aplicación CRUD que funciona sobre una base de datos.
Hay mucha información sobre cómo diseñar una cinta para aplicaciones basadas en documentos. El directrices de Microsoft incluso especifica pestañas y grupos estándar.
Sin embargo, estos grupos estándar no parecen ser ideales para situaciones sin documentos. El comando "Buscar", por ejemplo, debe estar dentro de un grupo "Edición":
Completamente relevante para buscar dentro un documento, pero no para buscar ¡para un registro.
¿Qué recursos y/o ejemplos existen para usar la cinta para aplicaciones que no son documentos?
Actualizado 27/9: Sí, estoy seguro de que un Ribbon es apropiado para la aplicación que estoy desarrollando. No está centrado en documentos, pero tampoco es CRUD puro: es una aplicación compleja con mucho comportamiento comercial. Sería más fácil para mí organizar un taller sobre cómo organizar la cinta si puedo proporcionar alguna orientación por adelantado, por lo que espero algunas respuestas a mi pregunta original sobre recursos y ejemplos.
Creo que el mejor ejemplo que puedes ver es MS Access. ¡Todos los comandos CRUD están en un grupo Registros y el comando Buscar está en el grupo Buscar!
La cinta fue diseñada para programas con muchos comandos, la aplicación CRUD tiende a tener solo unos pocos comandos, por lo que quizás la cinta no sea la UI correcta para empezar.
Puede hacer lo que hizo MS cuando diseñaron la cinta, tomar tantas personas como sea posible (que conocen el campo, preferiblemente clientes), luego dar una lista de pestañas/grupos y algunos comandos y dejar que elijan el lugar más lógico para el mando.
Y lo más importante, no siga ciegamente las pautas (pero tampoco las ignore sin una buena razón) y no confunda su preferencia personal con lo que los usuarios encuentran intuitivo.
Estoy casi en la misma situación que usted con mi aplicación y diseñando una interfaz "Ribbon". He contemplado una situación en la que agrupo comandos en la cinta de opciones en función del objeto central "comercial". En otras palabras, si mi aplicación permitiera a los usuarios administrar Clientes y Proveedores, tendría sentido tener un grupo de cintas dedicado a los Clientes, con todos los comandos que invocaría comúnmente y luego otro grupo de cintas dedicado a los Proveedores con los diversos comandos que hacen sentido correr contra esos objetos\registros?
Al esbozar esto, se hizo evidente (al menos para mí) que la administración de pantalla se volvería muy complicada con este estilo si solo proporcionara una sola cinta de opciones y probablemente frustraría más a los usuarios que ayuda.
La mejor interfaz de usuario con la que me he encontrado que trata al menos tangencialmente con este problema es la interfaz de Outlook 2010. Outlook se basa en un elemento de navegación separado, pero cuando cambia de Mensajes a Contactos, por ejemplo, la cinta de opciones cambia para mostrar los comandos admitidos para la interfaz con la que está trabajando en ese momento.
Volviendo a su ejemplo, parecería que Encontrar un registro particular implicaría que el usuario sabe el tipo de registro que está buscando. Puede tener sentido contar primero con un sistema de navegación para que el usuario pueda navegar al objeto central (por ejemplo, la vista de Clientes) y luego se le presente un conjunto de comandos dentro de la Cinta de opciones que se relacionan únicamente con los Clientes. En efecto, Buscar puede estar en el grupo "Edición", pero su contexto solo se refiere a la vista Clientes. También puede tener otro comando Buscar ubicado en un grupo de Edición que se relacione con alguna otra entidad dentro de la aplicación.
También he estado pensando en esto, y la idea principal que se me ocurrió es similar a lo que Tim Lentine describió: tener una pestaña para cada uno de mis principales objetos comerciales. Pondría los comandos más comúnmente ejecutados para ese objeto en la pestaña, por ejemplo, y el objeto "Ordenar" podría tener comandos para cambiar el estado (por ejemplo, cancelar, enviar, etc.), facturar, enviar factura, etc.
Sin embargo, también he estado pensando en cómo funciona la cinta en Windows Live Photo Gallery. En cierto modo, está gestionando una base de datos (de fotos y metadatos). De particular interés fueron las pestañas Inicio, Buscar y Ver. También me gustó la idea del cuadro de búsqueda/filtro que aparece.
Estas son las dos ideas principales de la cinta para una aplicación CRUD que he estado analizando. Sin embargo, todavía no he decidido nada.
En la línea de la galería de fotos, podría hacer una pestaña para recuperar una lista particular de datos y eliminarlos, etc. (planeaba hacer que el panel principal de mi ventana muestre una lista de objetos). Podría tener otro para filtrar/agrupar (similar a la pestaña 'vista' de WLPG). Probablemente tendría otra pestaña para informes. También podría usar pestañas contextuales para realizar comandos comunes en el objeto seleccionado como describí en el primer párrafo.
No tengo una amplia experiencia en una aplicación CRUD con una cinta, pero aquí hay algunas ideas ...
Leer - Tener una o más pestañas comprometidas con las formas estándar en que un usuario encontraría los objetos particulares. Por ejemplo, si se tratara de una base de datos de la universidad, una pestaña para estudiantes/facultad, una para clases, una para edificios. Agrupe los objetos en las pestañas por niveles más finos, como uno para estudiantes y otro para personal. Si se trata de una consulta de campo simple, puede colocar el control de texto sin formato directamente o abrir el cuadro de diálogo de búsqueda compleja.
Crear - solo tiene una pestaña para eliminar, o póngala en las pestañas de lectura. Si hace una pestaña de creación separada, haga que los grupos se asignen a las pestañas y agregue separadores para hacer mini-grupos.
Actualización - Consideraría seriamente las pestañas contextuales para esto. Un contexto por tipo de objeto. Si un formulario tiene varios tipos, tendrá que manejar el contexto mediante el enfoque del teclado. No es muy divertido También es posible que desee estas tareas de actualización en los propios formularios, especialmente si se asignan muy bien a las opciones de "comando" de diálogo como aplicar y tal.
Eliminar - Enterrado en el comando bien, no en la cinta por defecto. Destruir datos es algo que se debe desanimar. En cambio, aliente al usuario a 'archivar' o 'desaprobar' o 'graduar' los datos para que solo se muestren en consultas específicas. Y esas acciones son generalmente específicas del objeto, por lo que vivirían en los formularios o en las pestañas contextuales. Deje que las tareas semanales de copia de seguridad, archivo y mantenimiento hagan la eliminación.