Um outro aspecto importante a ser considerado refere-se à questão de facilidade de uso e administração dos sistemas em geral. Observe-se que não se pretende realizar uma análise sobre critérios de usabilidade, mas tão somente caracterizar a problemática envolvida na operação dos sistemas.
Conforme citado anteriormente, a realidade tem demonstrado que a atividade de administração de um sistema operacional é uma tarefa árdua, complexa e, muitas vezes, uma questão “vaga”, que depende da experiência de alguns chamados “gurus”. Esta afirmação pode ser considerada como uma verdade irrefutável para praticamente todos os sistemas operacionais já desenvolvidos. Vale também para aqueles mais “modernos” que possuem uma interface mais amigável com o usuário. Mais cedo ou mais tarde, seus segredos necessitarão ser devidamente ajustados por um profissional mais experiente para garantir um perfeito funcionamento (ou pelo menos próximo disto) do sistema alvo
(MATTOS, MARTINS e PACHECO,2000).
Um exemplo é o sistema operacional Unix. Desde o início da década de 80, inúmeros livros já foram publicados abordando vários de seus aspectos. Estes livros podem ser considerados de fundamental importância para usuários que estejam começando a utilizar aquele sistema operacional e até mesmo para os mais experientes. A tarefa de administrar um sistema operacional Unix envolve uma gama muito grande de
conhecimentos que abrange desde sua configuração, passa por ajustes de performance e chega até às mais complicadas soluções de problemas.
Esta dificuldade não é exclusiva dos sistemas Unix. Basta observar-se a vasta gama de cursos de certificação nas várias plataformas disponíveis e a solicitação cada vez maior por profissionais bem treinados para operar os diversos sistemas. Além disso, este problema é potencializado na medida em que as organizações passam a utilizar várias plataformas diferentes, em vários setores, com diversos níveis de exigência e conhecimento dos usuários finais(MATTOS, MARTINS e PACHECO,2000).
De acordo com Hugh(1997),
“Quando as interfaces com o usuário foram originalmente projetadas, não havia muita preocupação com a qualidade do que era apresentado, muito em função dos escassos recursos disponibilizados pelas mesmas (monitores monocromáticos de baixa resolução). Nesta época, as interfaces eram baseadas em caractere, em terminais alfanuméricos com teclas de função sendo utilizadas para complementar e/ou ativar funções especiais de uma aplicação. Contudo, a medida em que novos recursos foram sendo disponibilizados (monitores coloridos, com maior resolução) começaram a surgir questões relacionadas aos melhoramentos que poderiam ser realizados no sentido de minimizar os problemas de interação com as máquinas de forma a tornar seu uso mais fácil e eficiente. Em função destes esforços, começaram a surgir vários padrões e coleções de regras de usabilidade as quais levam em conta fatores técnicos e aspectos psicológicos do processo de interação”.
Nielsen (1994) apresenta um conjunto de 10 regras heurísticas que foram usadas para examinar uma base de dados contendo 249 relatos de problemas de usabilidade. Aplicando-as para avaliar o sistema operacional como um todo, pode-se chegar a algumas conclusões e identificarem-se alguns problemas ainda sem solução imediata, os quais são discutidos a seguir.
5.5.1 Visibilidade do estado do sistema:
Segundo Nielsen (1994), o sistema deve sempre manter os usuários informados
sobre o que está acontecendo, através de um feedback apropriado e dentro de um tempo razoável.
O nível de domínio do sistema restringe-se principalmente ao tratamento de exceções. Estas são de muito baixo nível e não agregam informação útil ao usuário. Se os programas são bem comportados, não há muito feedback a ser fornecido além dos tradicionais: quantidade de memória e disco disponíveis, percentagem de uso de processador, etc. Apesar de manter informações estatísticas e de estado dos periféricos e
demais componentes, estas informações não são imediatamente disponibilizadas às aplicações.
Hazzah (1997,pág.135) esclarece que no sistema operacional Windows 95, em determinadas situações, um device driver precisa escrever alguma informação na tela, mas como o subsistema de janelas está ocupado (busy), o que o sistema faz é chavear o modo de vídeo para modo texto e apresentar a mensagem neste modo.
Este é um exemplo de como o sistema operacional não tem controle absoluto sobre tudo o que nele está ocorrendo em determinado momento. Este tipo de ocorrência geralmente conduz a erros inesperados, visto que o sistema provavelmente entrou nesta situação a partir de uma transição de estados não prevista pelos projetistas.
5.5.2 Sincronismo (match) entre sistema e o mundo real
Segundo Nielsen (1994) o sistema deve falar a língua do usuário, com frases e
conceitos familiares, ao invés de usar termos do domínio do sistema, e seguir convenções do mundo real, fazendo as informações aparecerem de forma lógica e natural.
Figura 34 - Mensagem de erro quando o usuário tenta remover um arquivo do S.O.
Esta questão ainda está longe de ser solucionada, visto que, como afirmado acima, o sistema possui pouco conhecimento sobre seu real estado e, por outro lado, desconhece o perfil do usuário e das aplicações51. Esta afirmação deve ser analisada sob o seguinte aspecto: por um lado, o sistema possui estruturas de dados que descrevem a utilização de recursos da máquina, mas, por outro, não tem como saber o que determinada aplicação está efetivamente fazendo. Ao entregar o processador para a aplicação executar, qualquer 51Apesar de haver pesquisas neste sentido, conforme apresentado nas seção 4.3.3.
coisa pode acontecer. A Figura 34 apresenta uma mensagem de erro quando o procedimento de instalação de uma nova aplicação tenta remover um componente do próprio sistema operacional. Daí a necessidade da criação de mecanismos de proteção (senhas, permissões, etc). Quando o mecanismo não é genérico o suficiente, problemas acontecem.
5.5.3 Controle do usuário e liberdade
Segundo Nielsen (1994), eventualmente os usuários escolhem alguma função por
engano e necessitam de uma saída de emergência para sair deste estado sem ter que navegar por vários menus (Figura 35).
Figura 35 - Mensagem de aviso durante o cancelamento de operação com erro
Como o sistema não tem controle sobre a finalidade das aplicações, a busca dessa saída de emergência fica a cargo de cada aplicação, individualmente. Isto que faz com que o usuário necessite treinamento específico para cada tipo de aplicação e que ele perceba o comportamento geral do sistema como sendo orientado por aplicativos (Figura 36). É interessante observar que, por conta dessa anomalia, quando uma aplicação produz uma situação de erro a responsabilidade é geralmente imputada ao sistema operacional.
Figura 36- Associação entre formato de arquivo-aplicação.
5.5.4 Consistência e padronização
Segundo Nielsen (1994), os usuários não deveriam ter que se preocupar com diferentes palavras, situações ou ações que significam a mesma coisa. Em tais circunstâncias, eles devem seguir os padrões da plataforma:
Figura 37- Uso de linguagem técnica na interface com o usuário.
Esta questão é interessante. Sendo uma camada de software genérico, um sistema operacional, geralmente por questões mercadológicas, tem que manter compatibilidade com versões antigas de aplicativos, ao mesmo tempo em que insere novos conceitos de interface e recursos adicionais. Esta situação pode conduzir a ambigüidades na medida em que tarefas podem ser executadas de várias formas, dificultando o aprendizado de usuários menos experientes.
5.5.5 Prevenção de erros
Segundo Nielsen(1994),melhor do que apresentar mensagens de erro é desenvolver
um projeto que previna a ocorrência de problemas.
Esta questão remete a área de Engenharia de Software e todos os fatores associados a metodologias de desenvolvimento de sistemas, planejamento de testes e questões correlatas. No entanto, alguns problemas poderiam ser antecipados e solucionados pelo próprio sistema, ao invés de simplesmente reportar mensagens de erro. Pode-se imaginar a extensão do problema na situação em que determinado componente de um ambiente inteligente necessita ser reinicializado e solicita a confirmação do usuário antes de fazê- lo.
5.5.6 Identificar ao invés de relembrar
Segundo Nielsen(1994),os sistemas, de uma forma geral, deveriam tornar objetos,
ações e opções visíveis. O usuário não deveria ter que lembrar informações de um diálogo para outro. Instruções para uso do sistema deveriam ser visíveis ou facilmente recuperáveis sempre que apropriado.
Este é um dos aspectos mais críticos na interface dos atuais sistemas operacionais. Quando um problema acontece, freqüentemente torna-se necessário percorrer vários menus e aplicações para relembrar configurações atuais e corrigi-lo a partir delas. Por exemplo: configurações de rede.
5.5.7 Flexibilidade e eficiência de uso
Segundo Nielsen (1994), aceleradores podem agilizar a execução das tarefas por
usuários experientes Entretanto, em se tratando de usuários com pouca experiência, os aceleradores devem ser escondidos para permitir que eles utilizem conjuntos de ações freqüentes.
Aceleradores vêm sendo utilizados já há muito tempo em ambientes de sistemas operacionais, através de linguagens de scripts. Mas como seu uso requer um bom grau de conhecimento, eles se tornam ferramentas inúteis para usuários não especializados.
5.5.8 Projeto harmonioso e simples
Segundo Nielsen(1994), os menus não devem conter informações irrelevantes ou
raramente utilizadas. Em um diálogo, cada unidade extra de informação compete com questões relevantes e diminui sua visibilidade relativa.
Esta facilidade já pode ser encontrada em sistemas (Windows 2000, ME) e aplicativos (ex: pacote Office da Microsoft) mais recentes. Sua principal característica é a limpeza das listas de opções dos menus. No mesmo pacote Office encontra-se a figura do agente que procura antecipar ações do usuário, auxiliando, assim, os menos experientes e conhecedores. Deve-se observar, contudo, que essas melhorias estão restritas a aplicações específicas, não beneficiando o conjunto de todas as aplicações.
5.5.9 Auxiliar o usuário a reconhecer, diagnosticar e recuperar-se de erros.
Segundo Nielsen (1994), mensagens de erros não devem ser expressas através de códigos. Ao contrário, devem indicar precisamente o problema e sugerir soluções de forma construtiva.
Este aspecto está longe de ser solucionado. A própria estrutura de API dos sistemas é orientada por códigos de erro, o que conduz a mensagens semelhantes às apresentadas na Figura 38 e na Figura 39. Há algumas iniciativas para minimizar o efeito dos códigos de erro através do uso de wizards (Windows). Sua abrangência, no entanto, ainda é limitada. O apêndice 4 (seção 10.3,pág.363), apresenta mensagens sobre erros na forma de registros de log.
Figura 39- Mensagens de erro dependentes de API.
5.5.10Ajuda (help) e documentação
Segundo Nielsen (1994), mesmo que o sistema possa ser utilizado sem
documentação, ela pode ser necessária para prover auxilio em determinado momento. Qualquer fonte de informação deve ser concisa, de fácil consulta e orientada para tarefas, listando passos concretos a serem seguidos.
Esses requisitos, de certo modo, são conflitantes com as características de um sistema operacional, devido à sua abrangência e generalidade.
Hugh(1997) finaliza suas considerações sobre Human Computer Interaction (HCI) afirmando que a questão é complexa e que efetivamente não há um padrão estabelecido. Este problema é potencializado à medida que novas aplicações são incluídas no contexto de espaços inteligentes (Capítulo 3), onde a diversidade e a heterogeneidade de equipamentos interligados é muito maior e os requisitos de qualidade de serviço aumentam.