Modelos de interface SDI, MDI, TDI e NDI
Os programadores que viveram a época do modo texto em DOS tinham desafios bem diferentes ao projetar uma interface de usuário. Independente da linguagem utilizada - fosse Clipper, C, Pascal, FoxPro ou qualquer outra - as escolhas eram basicamente o melhor sistema de menu e a melhor combinação de caracteres de linha e cores de fundo e texto para diagramar as telas de 80 linhas por 25 colunas.
Na década de 90 os programadores descobriram a interface MDI (”Multiple Document Interface”) no Windows. Achavam o máximo aquele monte de janelas superpostas. Como o Delphi tornava muito fácil criar esse tipo de interface, qualquer programinha tinha múltiplas janelas flutuando na área cliente e não faltavam aquelas famigeradas opções de janelas em cascata, lado-a-lado, minimizadas, etc. A gente se sentia até orgulhoso de fazer um sistema com interface semelhante à do Office. Melhor ainda se os ícones fossem os mesmos da Microsoft.
O que nós desenvolvedores ignorávamos então é que os usuários finais não dão a mínima pra nada disso. Os usuários gostam de fazer uma coisa de cada vez, com início, meio e fim. Lidar com várias janelas abertas na mesma aplicação só torna mais confuso o trabalho.
Muitos se assutaram quando o próprio Office, que havia popularizado o modelo MDI, abandonou a estratégia. A Microsoft fez muitas pesquisas de opinião e laboratórios de usabilidade para chegar a conclusão que não valia a pena insistir naquilo. Ficamos perdidos em busca de um novo modelo de interface de usuário.
A alguns anos veio com o FireFox e outros navegadores modernos a inspiração para uma idéia salvadora: apresentar janelas em páginas selecionáveis por abas. Definiu-se um novo modelo, que alguns chamam de TDI (”Tabbed Document Interface”), em oposição ao antigo MDI. As janelas abertas (documentos) são fáceis de visualizar e selecionar. Cada aba utiliza grande parte da área cliente, dando ao usuário a confortável sensação que está sempre trabalhando com uma janela “maximizada”.
É fácil, no entanto, observar que os usuários finais preferem. O mais simples e direto modelo de interface é o mais eficaz. Muitas vezes os mais complexos modelos de interação acabam reduzidos pela forma com que o usuários utilizam a um modelo simples de uma única janela que ocupa toda área do monitor, conhecido como SDI (”Single Document Interface”).
A propósito, qual seria o modelo de interface de um sistema web? Pense no Americanas.com, no Orkut e no site do seu supermercado favorito. Não é TDI, nem MDI, evidentemente. Cada página funciona na mesma área cliente, alternando-se conforme o opção escolhida pelo usuário. O que mais se aproxima é o bom e velho SDI.
Todos esses modelos de interface têm uma coisa em comum: o conceito de documento. Seja um documento de texto, uma planilha eletrônica ou uma página web, todos os documentos são da mesma natureza em uma interface MDI, TDI ou SDI.
Ainda hoje, por falta de opção ou por retrógrada herança da cultura de modo texto dos anos 80 muitos desenvolvedores ainda utilizam uma grande tela vazia (ou pior, um imenso bitmap espalhafatoso com o logo da empresa no fundo), um menu e uma barra de botões no topo da janela e mais nada. Esse modelo é o que se pode chamar NDI: “No Document Interface”. A cada opção de menu, abre-se uma caixa de diálogo diferente. Pode não ser bonito ou elegante, mas é funcional. Os clientes entendem.
O fato é que os usuários imediatamente absorvem a metáfora do menu que abre e fecha opções e volta ao estado inicial. Dá até para imaginar um usuário ensinando a outro como usar a aplicação: “Escolhe essa opção para cadastrar e essa outra para tirar um relatório…”.
Janelas e Documentos
Trazer o conceito de documentos para um cliente nativo Windows não é fácil. Pelo menos, não é óbvio. Aplicações de negócio têm relatórios, telas de cadastro, consulta e configuração e lidam com grupos de informação diferentes (clientes, produtos e vendas, por exemplo), cada um com uma forma de apresentação própria.
Na busca de um modelo orientado a documentos, seja TDI ou mesmo SDI, torna-se necessário definir um tipo abstrato de objeto que possa representar todos os tipos de telas que se deseje apresentar na aplicação, similar ao conceito de documento dos browsers e editores de texto.
O Delphi não traz nada disso pronto, mas oferece inúmeros recursos que possibilitam a sua implementação. A chave é a programação orientada a objetos. Veja bem, eu disse programação, não interface orientada a objetos.
Uma hierarquia de classes de forms é chamada “herança visual” na VCL. Podemos usar herança visual para definir um form base que implemente o conceito de documento numa interface TDI ou SDI.
É razoável que todos os forms documento tenham alguma funcionalidade em comum. Todos os “documentos” podem ser abertos (abrir datasets, iniciar controles), fechados (fechar datasets, liberar objetos de memória), copiar para clipboard (seja um TEdit ou um TChart) e muitos até impressos. Esses são exemplos de ações comuns. Outras, no entanto, não podem ser abstraídas sem prejuízo de entendimento. Por exemplo, “Calcular” não é um bom candidato para uma ação comum, porque não é natural calcular um cadastro, por exemplo.
Há várias formas de implementar funções específicas de um tipo de documento: botões direto na janela, objetos TAction integrados em um TActionList global, menu merge, etc.
Balancear o que deve ser abstraído e o que deve ser especializado é sutil. Isso vale, é bem verdade, para todos os modelos de representação hierárquica e orientada a objetos, de modelos de dados a interfaces de usuário. Felizmente, no caso das interfaces de usuário você sempre tem o recurso de sair da sua mesa e ir perguntar os maiores interessadods, os usuários: “Para você, o que é melhor?”.
Comments
6 Responses to “Modelos de interface SDI, MDI, TDI e NDI”
Deixe uma Resposta
-
-
Sobre
Malta on Delphi é um site de artigos técnicos originais sobre Delphi.
-
Blogroll
Exatamente isso ! Seu último parágrafo diz tudo, mas discordo onde você diz que “o usuário gosta de fazer uma coisa de cada vez”, na verdade, não é ele que define isso. Vejo sistemas onde o cliente está cadastrando um cliente e precisa verificar um pedido, simplesmente ele “abre” outro vez o sistema e pesquisa o pedido. Nesse meio tempo é preciso imprimir um boleto e ele não pode deixar o cadastro de clientes nem o de pedidos…já vai outro programa aberto.
Hoje é fundamental o usuário ter liberade de abrir quantas vezes quiser o cadastro de clientes e isso não atrapalha em nada o trabalho dele.
Vide sistemas como SAP, Microsiga, Datasul…nenhum é SDI, o usuário tem liberade.
Caso queira, posso te enviar umas telas do meu sistema em Delphi e mostrar como consegui deixa-lo funcional e sem complicação para o usuário.
Discordo completamente sobre usuário preferir o modelo SDI. O Dener citou o exemplo que presenciei várias vezes: o usuário está preenchendo um cadastro e para pesquisar ou executar outra tarefa, tem que “perder” os dados. E o pior de tudo é que com o tempo eles acham este procedimento normal!
Minha regra básica: o que você como desenvolvedor e usuário gosta na interface de suas ferramentas? Replique-as para seus usuários.
Você gosta de trabalhar com SDI? Primeiro altera o .pas, depois acessa o object inspector, por favor, né!
Parece que eu consegui criar alguma polêmica… :) Esperava que o artigo traria opiniões fortes contra e a favor, mas parece que fui um pouco mal interpretado nesses primeiros comentários.
Eu não estabeleci que SDI fosse o melhor modelo. O que eu disse é que “o mais simples e direto modelo de interface é o mais eficaz”. Ao ponto que usuários chegam até a reduzir uma aplicação MDI pela forma como a utilizam em SDI, ignorando o fato que poderiam usar múltiplas janelas.
Na segunda parte (”Janelas e Documentos”) inicio uma discussão conceitual sobre os requisitos para fazer qualquer tipo de aplicação de múltiplos documentos, o contrário de um SDI.
Aliás, como bem notou Dener, cada caso é um caso e os usuários é que devem ser consultados sempre. Se os usuários forem engenheiros ou programadores acostumados a interfaces ricas e complexas com milhares de informações na tela, panels, toolbars e janelas abertas simultaneamente, amém.
No artigo eu defendo duas opiniões:
(1) que MDI é muito ruim (sempre) e
(2) que uma tela vazia com menu principal é funcional, mas é muito feio
Sandro, eu penso exatamente o oposto da sua regra básica. Fazer aplicações para usuários finais como réplicas de interfaces de usuários programadores é um caminho muito perigoso. iPod, iPhone, Linux Ubuntu e Mac OS são exemplos de produtos que são grande sucesso de público justamente porque têm interfaces simples e ergonômicas, adaptadas às características dos usuários comuns.
Fica o questionamento. Como podemos aprender com o exemplo de simplicidade e usabilidade desses produtos?
Eu sou a favor do padrão SDI, usando formulários padrões e herança em vários outros forms. Tenho sistemas públicos e comerciais, e sempre gostei de ter o controle e foco do usuário. Estou começando um novo projeto, e neste vou usar TDI, pois se ajusta ao meus estilo de forms e dá alguma liberdade ao cliente sem mostrar forms sobrepostos.
Roberto.
“SAP, Microsiga, Datasul…” … heheheheh ..
Sensacional!!!!
Ganhamos um bom dinherinho graças a essa… digamos .. “tendência de mercado”!!!
Vlw! Matla, concordo em gênero, número e grau com vc!
Parabéns pela paciência e tolerância!
Fala Malta, tudo bom cara?!
Não vou opinar sobre MDI pq quando comecei a programar em Delphi de _cara_ não gostei do modelo, eu nunca fui fã de programas que os Forms filhos abrem no meio do Form pai, já chega de ficar tão dependente das “regras Micr0$0ft”, e dependendo da forma como o programador interpreta a coisa, termina com um usuário final abrindo um monte de transações e tb esquecendo alguns Forms filhos abertos (minimizados) sem necessidade.
Uma vez fui numa clínica fazer uma consulta e fiquei perplexo com a quantidade de Forms (Childs) minimizados no frmMain, cara, ali nem um “restore all” daria conta.
Eu até perguntei “… vc sabe o que tem em cada janelinha aberta?”. R.: “… Não!”.
Concordo com vc sobre o SDI, seguinte, precisou [visualizar/importar/salvar] dados em outra tabela, use e abuse de _dblookups_, coloca um botão pequeno do lado do db-aware com um “…” e um Hint “Importar editar ou inserir novos dados em Nome da tabela”.
De tanto eu usar a técnica já criei um componente, baseado no AdvDBPopupList, dá até para definir um SQL para limitar a quantidade de dados que vai aparecer no DBGrid do popup.
Só vou soltar o source quando eu tiver portado o bicho inteiro para o Lazarus :D.
Parabéns pelo post!