Fórum Acessibilidade x Navegação x Interface #329181

Cara,

Nos meus sistemas, quando o usuário clica em um módulo (clientes, por exemplo), a primeira interface que abre é a de consulta onde tem um grid que mostra todos os dados cadastrados.
Faço dessa forma pelo seguinte:
1- As inclusões são realizadas em maior número apenas no período inicial de implantação do sistema. Depois de um certo tempo, a maioria das operações são consultas e atualizações de dados, e para isso o usuário tem que pesquisar no cadastro para encontrar o registro que ele precisa alterar.
2- O grid mantém as informações sempre visíveis, o que facilita a detecção de erros de digitação, por exemplo.
3- Os relatórios (dos meus sistemas) são emitidos com base nas informações que estão sendo exibidas no grid. Então, ao invés de ter um monte de relatórios pré-definidos o usuário monta seus próprios relatórios e filtra os dados que necessita, diretamente no Grid.
4- Nem sempre os usuários lembram o código ou o nome completo de seus clientes. Neste caso, olhando os dados no grid fica mais fácil e depois que ele encontra o cliente que precisa, basta ele dar um clique duplo sobre o cliente para que a interface de cadastro/alteração apareça.

Ao meu ver esta é a melhor alternativa, mas acho que vc deve fazer uma análise detalhada dos objetivos do seu sistema, da rotina de trabalho que as duas formas de apresentação vao gerar (quanto mais passos, ou cliques, o usuário tiver que executar para acessar a informação, mais complicado ele vai considerar seu sistema) e principalmente o perfil dos usuários deste sistema.

Outra opção é você tornar essas alternativas configuráveis pelo usuário. Assim ele escolhe a opção que mais se adapta ao seu perfil.

De qualquer forma acho que não dá pra jogar todos os sistemas que vc vai fazer em um pacotão e fazer todos da mesma forma. Cada um tem suas prioridades e deve ser analizado separadamente.

Já ouvi muitas opiniões sobre esse assunto, mais vou contar como trabalho, primeiramente gostaria de afirmar que: Não gosto de usar Grids, porém, são essenciais para uma boa visualização de vários dados na tela do usuário ao mesmo tempo. Eu penso da seguinte forma, dependendo do tipo de sistema, onde será aplicado, como será aplicado, quantos terminais existiram ligados ao servidor, se é uma aplicação Client/Server ou não. Tudo são fatores que implicam diretamente na minha visão de desenvolvimento, sei que não posso desenvolver um software pensando no hoje e sim no amanhã, como será o seu desempenho daqui a alguns anos, por outro lado existem determinadas partes do sistema em que as informações a serem exibidas devem ser as mais resumidas possíveis, por exemplo: Se você vai carregar uma Grade com informações diversas sobre algo no seu sistema, seja Clientes, Ultimas Vendas, Contas a Pagar, Receber, Histórico de Devedores, sei lá. Devemos ter muito cuidado quanto a essas informações, pois, sabemos que o desempenho do sistema depende muito da quantidade de informação que ele solicita do banco, então, eu defendo a forma de trabalhar no modo Back-End em determinadas partes do sistema e no modo Front-End em outras.
Value :wink:

Caro, Amigo. Tudo jóia?

Veja, eu tenho clientes que tem telas, no mesmo sistema, que apresenta as duas opções que vc mencionou. Na minha opinião isso vai depender da forma que o seu cliente trabalha, no meu caso, eu pedi a opinião dele. Ofereci as duas opções e ele escolheu as telas que receberiam, primeiro, o grid, para consulta e depois o cadastro. E em outros casos, eu fiz o contrário. As duas idéias são excelentes, isso fica a critério do seu cliente.

Caros Colegas,

como o Rafael e o Paulo observaram, pensando e repensando sobre o assunto, acredito que poderia dividir o desenvolvimento da seguinte forma, tudo isso se tratando de um sistema genérico (desktop): utilizaria a exibição dos dados como back-end nos módulos cadastrais, ou seja, aqueles que não possuem [b:97cfe5a8ab]grande[/b:97cfe5a8ab] variações de informações e nos restantes dos módulo a exibição viria como front-end, contudo, deve haver flexibilidade nesse conceito, pois a opinião do cliente deve ser respeitada e como os colegas frisaram ´cada caso é um caso´....já na plataforma web (utilizo IW-intraweb), acredito que a exibição dos dados deve-se ter uma atenção maior, levando em consideração a velocidade de resposta da aplicação e quantidade de registros, tendo a paginação como viabilização desse processo.

O que os colegas acham sobre essa proposta ??

Att, Maiki Perin.

Maiki, bom dia

Realmente é um assunto que vale um debate entre os desenvolvedores, bem vou tentar repassar a forma como eu trabalho.

De fato como os nossos amigos descrevam varia de sistema para sistema, e o volume de dados que serão inseridos e consultados, atualmente trabalho em um sistema que envolve muitos cadastro de dados, desta forma é inviável o desenvolvimento dos forms apresentando primeiramente os dados cadastrados em grids, os forms foram desenvolvidos de forma separadas, tudo para aumentar a agilidade nas inclusões. Caso o usuário deseje efetuar uma alteração ou exclusão, ele deverá consultar os registro em uma janela distinta da janela de inclusão.

Agora para web tenho visto que a maioria dos sistemas administrativos optam por mostrar primeiramente um grid com os registros paginados, e muita das vezes existem filtros e modos de ordenação para este grid, estas técnicas tem se mostrado eficiênte ainda mais agora com o avanço da metodologia de desenvolvimento WEB o ´AJAX´, pois algum tempo atrás a utilização destes filtros era um tanto chato, pois caso você alterasse a forma de apresentação dos dados toda a página era carregada novamente.


Abraços

Bom, eu também costumo utilizar esse conceito da tela de consulta ter um tipo de ´PageControl´ em que uma aba é a listagem dos registros e outra a edição do mesmo, acho um conceito tranquilo de ser trabalhado na maioria dos casos, pois, há casos como o que temos na empresa que trabalho hoje, em que se abrimos uma determinada tela com a query do cadastro aberta, essa tela vai demorar uns 30seg ou mais para abrir, e pra esses casos especificos tivemos que criar uma opção na função de criação da tela se ela deve abrir ou não a mesma, e neste caso abrir na aba de edição.

mas de acordo com o que foi proposto aqui, poderia-se também criar um check box nela em que o usuário poderia definir se ele quer abrir a tela em ´modo de edição´ ou listagem ficaria algo realmente mais interessante. Bastaria definir qual o melhor lugar para salvar essa informação no banco ou no registre?

Bom, eu também costumo utilizar esse conceito da tela de consulta ter um tipo de ´PageControl´ em que uma aba é a listagem dos registros e outra a edição do mesmo, acho um conceito tranquilo de ser trabalhado na maioria dos casos, pois, há casos como o que temos na empresa que trabalho hoje, em que se abrimos uma determinada tela com a query do cadastro aberta, essa tela vai demorar uns 30seg ou mais para abrir, e pra esses casos especificos tivemos que criar uma opção na função de criação da tela se ela deve abrir ou não a mesma, e neste caso abrir na aba de edição.

mas de acordo com o que foi proposto aqui, poderia-se também criar um check box nela em que o usuário poderia definir se ele quer abrir a tela em ´modo de edição´ ou listagem ficaria algo realmente mais interessante. Bastaria definir qual o melhor lugar para salvar essa informação no banco ou no registre?

eu particularmente não gosto da idéia de uma tela para cadastro e uma outro para pesquisa.
faço o seguinte, quando o cliente abre por exemplo o cadastro de clientes, abro uma tela pronta para edição sem nenhum registro. caso o usuário queira localizar um registro, nesta mesma tela tem o botão pesquisar, onde o usuário digita parte do nome( ou por algum outro campo q queira) e então será exibido os registros localizados em uma tela de pesquisa pequena, e selecionando o registro esta tela é fechada e o registro é carregado na tela grande.