O desenvolvimento de uma Interface é um processo particularmente complexo. Para além dos aspectos metodológicos e tecnológicos presentes no desenvolvimento de qualquer sistema software, é necessário ter também em consideração aspectos da área de factores humanos: ergonomia, consistência, facilidade de aprendizagem, etc.
A área de Interacção Humano-Computador (IHC) surge como resposta a esta constatação. Os primeiros trabalhos na área foram efectuados no âmbito da Computação Gráfica e estavam relacionados com aspectos de factores humanos [HH89]. Centenas de regras foram compiladas, embora apenas uma pequena parte tenha sido objecto de validação experimental. Estas regras visavam fundamentalmente definir quais as características de uma boa Interface; não definiam, no entanto, como se deveria desenvolver uma interface de modo a que lhes obedecesse, ou como provar que uma dada interface as verificava.
Com a crescente complexidade dos Sistemas Interactivos, tornou-se evidente serem necessárias, para construir interfaces que obedecessem a essas regras e princípios, ferramentas e metodologias que auxiliassem e guiassem o seu desenvolvimento. Tratava-se de passar de uma fase em que a interface era programada de uma forma mais ou menos ad hoc, para outra em que ela podia ser descrita e gerada utilizando metodologias e ferramentas apropriadas. Um marco importante nesta transição foi o estabelecimento do Princípio da Separação (ou da Independência de Diálogo), que propõe que uma aplicação interactiva esteja dividida em duas camadas: a camada computacional, correspondente à aplicação propriamente dita, e a camada de diálogo, responsável pela comunicação entre o utilizador e a camada computacional. O princípio diz ainda serem as duas camadas independentes, tanto a nível de desenho como de implementação.
Foi a partir deste ponto que a IHC se pôde afirmar como área de estudo autónoma, pois o desenho e desenvolvimento da camada interactiva passaram a estar separados do desenho e desenvolvimento da camada computacional.
Para além de permitir o estudo, de modo independente, de metodologias e técnicas óptimas para cada uma das componentes, a adopção deste princípio tem ainda a vantagem de permitir que alterações feitas numa das camadas (principalmente a nível de implementação) possam ter poucas implicações (ou mesmo nenhuma) na outra. A sua implementação é, no entanto, difícil de conseguir e a necessidade de comunicação entre as camadas provoca alguma degradação do desempenho.
Uma primeira forma rudimentar do Princípio da Separação pode ser reconhecida no aparecimento do conceito de device independence, que isolou o programador das características particulares dos diferentes aparelhos de interacção.
Numa segunda fase surgiram os geradores de aplicações, que permitiam descrever em linguagens de alto nível os écrans e as leituras da aplicação, e os Toolkits, colecções de rotinas de tratamento de écran e leitura/escrita. Exemplos de Toolkits conhecidos são o Smalltalk-MVC [Dig87], SunView [Sun90], Xtoolkit [QO90a], Macintosh Toolbox [Ste87], DesQView/X [Rad90] ou o MsWindows [Ste87]. Um tipo particularmente importante de Toolkit são os Window Systems, vocacionados para fornecerem serviços de gestão de Workstations. Dividem o écran físico em écrans virtuais (chamados janelas) possibilitando o desenrolar de várias sessões de trabalho em simultâneo no mesmo posto de trabalho, estando a cada uma delas associada uma janela principal.
Podemos identificar dois tipos básicos de Window Systems. Os Kernel Based, que são construídos como extensões ao sistema operativo - pelo que ficam limitados à máquina em que estão a ser executados (por exemplo SunView e MsWindows) -, e os Cliente-Servidor, nos quais o Window System passa a ser mais um processo na máquina, funcionando como servidor de pedidos gráficos e de leitura/escrita. Deste modo, é possível ter um processo remoto a fazer pedidos ao Window System através da rede e, assim, utilizar os dispositivos de entrada e saída de dados da máquina local. Exemplos deste tipo são o X11 [QO90b] e o NeWS [Ros87].
Com estas ferramentas, era já possível separar o desenho e a implementação da componente de diálogo do desenho e implementação da camada computacional de uma aplicação interactiva. Esta separação dependeria, no entanto, de uma vontade deliberada da equipa de desenvolvimento do sistema para a obter, já que as ferramentas, por si só, não a garantem. Elas limitam-se a fornecer serviços, não impondo políticas. Nesta fase, embora fosse possível implementar Independência de Diálogo, ela não era, ainda, verdadeiramente suportada pelas ferramentas disponíveis.
Foi com o aparecimento dos Sistemas de Gestão da Interface com o Utilizador (SGIU) que o Princípio da Separação passou a ser realmente suportado. Um SGIU é um conjunto de ferramentas para o desenho e a execução da componente de diálogo dos sistemas interactivos [GR90][CC90] que permite desenvolver a Interface de um modo independente do desenvolvimento da componente computacional. Idealmente deverá proporcionar um ambiente interactivo para o desenho, prototipagem, avaliação, implementação ou execução e manutenção de Interfaces com o Utilizador [HH89][BCMR90]. É importante não confundir um SGIU com um Toolkit, pois este último fornece facilidades para o desenvolvimento da Interface, mas não um ambiente integrado e uma metodologia para esse desenvolvimento.
A separação entre componente de diálogo e componente computacional, levanta o problema de decidir quem tem o controlo sobre o funcionamento global do sistema. Quando é a componente interactiva a controlar o funcionamento do sistema, a componente computacional é vista como um conjunto de rotinas que a primeira invoca quando necessário, estamos perante o controlo Dialogue Dominant. Na situação inversa, em que o controlo está na componente computacional, dizemos que este é Computacional Dominant. Entre estes dois extremos podemos ter um controlo misto (as duas componentes invocam-se mutuamente) ou balanceado (existe uma terceira componente que o detém).
Um outro aspecto importante a ter em conta quando se pensa em Interacção Humano-Computador, tem a ver com o tipo de diálogo que pretendemos. Podemos identificar dois tipos básicos de diálogo [Mar92]: diálogo sequencial e diálogo assíncrono. Na categoria de diálogos sequenciais então incluídas interacções do tipo pedido-resposta, linguagens de comandos, navegação por hierarquias de menus e data entry. A principal característica dos diálogos sequenciais é a de que, em cada instante, o sistema apresenta apenas uma tarefa ao utilizador. Em diálogos assíncronos são apresentadas ao utilizador, em cada instante, diversas tarefas que ele pode realizar. Incluídas neste tipo de diálogo encontram-se normalmente as interfaces por manipulação directa. Nestas, o utilizador realiza operações manipulando representações visuais dos objectos (os icons): se, por exemplo, quiser remover um ficheiro, coloca-o (o seu icon) sobre o cesto do lixo (o icon da operação de remoção). Associado a este tipo de interacção está o conceito de diálogo multi-thread, numa referência à possibilidade que é dada ao utilizador de, em cada momento, prosseguir o diálogo segundo vários caminhos. Se mais que uma tarefa puder ser executada ao mesmo tempo, então o diálogo diz-se concorrente. Embora os dois tipos de interacção sejam utilizados, a tendência é cada vez mais para os diálogos assíncronos, principalmente por manipulação directa, dada a sua aparente maior facilidade de aprendizagem e utilização.
Com o objectivo de conseguir interfaces cada vez mais amigáveis, tem sido levadas a cabo tentativas, especialmente no âmbito da Inteligência Artificial, para incorporar nas interfaces Modelos do Utilizador [MF93]. Deste modo o sistema interactivo tenta analisar o comportamento do utilizador e, por reacção, adaptar-se, em cada momento, às suas capacidades e conhecimento. Tais trabalhos não têm conseguido, no entanto, tanto sucesso como o esperado, pelo que abordagens alternativas têm sido procuradas.
Em [MO90] é argumentado que a complexidade inerente ao ser humano implicará sempre uma incompletude desses modelos face à realidade e em consequência tais interfaces serão sempre, em maior ou menor grau, inadequadas e ineficazes. Para a resolução deste problema é proposta a utilização de modelos implícitos do utilizador. Se conseguirmos identificar as características humanas que podem influenciar o desempenho de um sistema interactivo e concebê-lo de modo a que actue de modo preventivo em relação às mesmas, teremos o problema resolvido. A ideia é então, não reagir a posteriori às acções do utilizador, mas agir de um modo preventivo, guiando a interacção de modo a que este não cometa erros e utilize o sistema de uma forma correcta. A este modo de interacção chamou-se Modo Assistido.
Para a definição de Modo Assistido são consideradas como essenciais as seguintes características do utilizador:
Se para um utilizador novato uma interface por menus é, normalmente, mais intuitiva e fácil de utilizar, já um utilizador experiente consegue, usualmente, maior produtividade pela utilização directa dos comandos. Uma interface em Modo Assistido deverá, então, prever dois tipos de interacção:
Sempre que em Modo Comando for detectado algum erro, deverá ser efectuada a mudança automática para Modo Assistido, facilitando, assim, a correção do mesmo.