it-swarm-pt.com

Projetando uma fita fluente para um aplicativo CRUD

Estou trabalhando no design de um UX estilo Fluent ("Ribbon") para um aplicativo CRUD que trabalha em um banco de dados.

Há muitas informações sobre como criar uma faixa de opções para aplicativos baseados em documentos. O diretrizes da Microsoft até especifica guias e grupos padrão.

No entanto, esses grupos padrão não parecem se encaixar perfeitamente em situações que não são documentos. O comando "Localizar", por exemplo, deve estar dentro de um grupo "Edição":

alt text

Inteiramente relevante para pesquisar dentro um documento, mas não para pesquisar para um registro.

Que recursos e/ou exemplos existem para usar a faixa de opções em aplicativos que não são documentos?

Atualizado em 27/9: Sim, tenho certeza de que uma faixa de opções é apropriada para o aplicativo que estou desenvolvendo. Ele não é focado em documentos, mas também não é um CRUD puro - é um aplicativo complexo com muito comportamento nos negócios. Será mais fácil para mim realizar um workshop sobre como organizar a faixa de opções, se eu puder fornecer algumas orientações com antecedência - por isso, espero respostas para minha pergunta original sobre recursos e exemplos.

14
Bevan

Eu acho que o melhor exemplo que você pode ver é o MS Access. Todos os comandos CRUD estão em um grupo Registros e o comando Localizar está no grupo Localizar!

alt text

14
Tania Gobeil

A faixa de opções foi projetada para programas com muitos comandos; o aplicativo CRUD costuma ter apenas alguns comandos; portanto, talvez a faixa de opções não seja a interface do usuário correta para começar.

Você pode fazer o que a MS fez ao projetar a faixa de opções, levar o maior número possível de pessoas (que conhecem o campo, de preferência clientes), fornecer uma lista de guias/grupos e alguns comandos e deixá-los escolher o local mais lógico para o comando.

E o mais importante, não siga cegamente as diretrizes (mas também não as ignore sem uma boa razão) e não confunda sua preferência pessoal com o que os usuários acham intuitivo.

11
Nir

Estou quase na mesma situação em que você está com meu aplicativo e criando uma interface "Ribbon". Contemplei uma situação em que agrupo comandos na faixa de opções com base no objeto "comercial" principal. Em outras palavras, se meu aplicativo permitisse aos usuários gerenciar clientes e fornecedores, faria sentido ter um grupo de faixa de opções dedicado a clientes, com todos os comandos que você normalmente chamaria e outro grupo de faixa de opções dedicado a fornecedores com os vários comandos que fazem sentido correr contra esses objetos\registros?

Ao esboçar isso, ficou claro (pelo menos para mim) que o gerenciamento de tela se tornaria muito complicado com esse estilo se eu desse apenas uma faixa de opções e provavelmente frustrasse os usuários mais do que ajudar.

A melhor interface do usuário que me deparei que lida pelo menos de maneira tangencial com esse problema é a interface do Outlook 2010. O Outlook depende de um elemento de navegação separado, mas quando você alterna de Mensagens para Contatos, por exemplo, a Faixa de Opções muda para mostrar os comandos suportados para a interface com a qual você está trabalhando no momento.

Voltando ao seu exemplo, parece que a localização de um registro específico implica que o usuário saiba o tipo de registro que está procurando. Pode fazer sentido primeiro instalar um sistema de navegação para que o usuário possa navegar até o objeto principal (por exemplo, exibição de Clientes) e depois ser apresentado a um conjunto de comandos na Faixa de Opções que se relacionam exclusivamente aos Clientes. A localização pode realmente estar no grupo "Edição", mas seu contexto pertence apenas à visualização Clientes. Você também pode ter outro comando Localizar localizado em um grupo de Edição relacionado a alguma outra entidade no aplicativo.

3
Tim Lentine

Também estive pensando sobre isso, e a idéia principal que me surgiu é semelhante ao que Tim Lentine descreveu: ter uma guia para cada um dos meus principais objetos de negócios. Eu colocaria os comandos mais executados para esse objeto na guia, por exemplo, e o objeto "Pedido" pode ter um comando para alterar o status (por exemplo, cancelar, enviar, etc.), faturar, enviar fatura etc.

No entanto, também estive pensando em como a faixa de opções na Galeria de Fotos do Windows Live funciona. De certa forma, é gerenciar um banco de dados (de fotos e metadados). De particular interesse foram as guias Início, Localizar e Exibir. Eu também gostei da ideia da caixa de pesquisa/filtro que aparece.

photo gallery ribbon

Portanto, essas são as duas principais idéias da faixa de opções para um aplicativo CRUD que eu tenho ponderado. Ainda não decidi nada ainda.

Nas linhas da galeria de fotos, eu poderia fazer uma guia para recuperar uma lista específica de dados e excluir etc. (planejava fazer com que o painel principal da minha janela exibisse uma lista de objetos). Eu posso ter outro para filtrar/agrupar (semelhante à guia 'view' do WLPG). Eu provavelmente teria outra guia para relatórios. Também posso usar guias contextuais para executar comandos comuns no objeto selecionado, como descrevi no primeiro parágrafo.

2
Benny Jobigan

Não tenho vasta experiência em um aplicativo CRUD com uma fita, mas aqui estão algumas idéias ...

Ler - Tenha uma ou mais guias comprometidas com as formas padrão pelas quais um usuário encontraria os objetos específicos. Por exemplo, se fosse um banco de dados da faculdade, uma guia para alunos/corpo docente, uma para aulas e outra para edifícios. Agrupe os objetos nas guias por níveis mais refinados, como um para estudantes e outro para funcionários. Se for uma consulta de campo simples, você poderá colocar o controle de texto sem formatação diretamente ou abrir a caixa de diálogo de pesquisa complexa.

Criar - possui apenas uma guia para excluir ou coloca-a nas guias de leitura. Se você criar uma guia de criação separada, faça com que os grupos sejam mapeados para as guias e adicione separadores para criar mini-grupos.

Atualização - Eu consideraria seriamente as guias contextuais para isso. Um contexto por tipo de objeto. Se um formulário tiver vários tipos, você precisará direcionar o contexto pelo foco do teclado. Não é tão divertido. Você também pode querer essas tarefas de atualização nos próprios formulários, especialmente se elas forem bem mapeadas para as opções de 'comando' da caixa de diálogo, como apply e tal.

Excluir - Enterrado bem no comando, não na faixa de opções por padrão. Destruir dados é algo a ser desencorajado. Em vez disso, incentive o usuário a 'arquivar' ou 'descontinuar' ou 'graduar' os dados para que eles apareçam apenas em consultas específicas. E essas ações geralmente são específicas de um objeto, para que elas vivessem nas formas ou nas guias contextuais. Deixe as tarefas semanais de backup, arquivamento e manutenção fazerem a exclusão.

0
shemnon