2006-01-26

Interface humana, parte 2: os velhos problemas

Na parte anterior, terminei falando que as interfaces dos sistemas de computadores sofrem de problemas conceituais. No fundo, elas estão atrasadas em relação ao que se já sabe sobre o funcionamento da mente humana. Nós às vezes ficamos confusos porque os softwares funcionam da maneira que é mais conveniente para eles mesmos, não da maneira mais conveniente para nós. Mas na maior parte do tempo não percebemos a contra-intuitividade dos computadores porque, em boa medida, fomos treinados a pensar como eles.
Vou analisar alguns elementos de interface triviais que poderiam ser eliminados ou aprimorados no atual estado da tecnologia.

Não temos nenhuma necessidade lógica mental de que cada documento seja repetidamente salvo no disco por nós mesmos enquanto trabalhamos. O comando de salvar é remanescente de uma época em que os sistemas eram burros demais para cuidar disso. Mas eles também não sabiam alocar memória e processador dinamicamente... e hoje sabem. Alguns programas bem antigos salvam o arquivo automaticamente de tantos em tantos minutos, mas não é disso que estou falando, e sim a capacidade de gravar tudo o que você faz em tempo real, sem necessidade de nenhum comando.
Surpresa: o Adobe InDesign faz exatamente isso. Em caso de falha de energia ou outra interrupção brusca, ele reabre os arquivos exatamente como estavam no momento do problema. A existência desse recurso (que já salvou meu trabalho várias vezes) num programa comercial importante prova que só falta "vontade política" para os demais aplicativos serem assim também.

Outro recurso padrão das interfaces gráficas que poderia ser eliminado sem dó é o duplo-clique. Sempre fui contra, pois é contra-intuitivo, pode ser acionado acidentalmente e cansa os tendões. A prova de que ele não é necessário é o recurso "navegar nas pastas como na Web" do Windows e a navegação por colunas do Mac OS X. Aliás, em ambos o sistemas navegar pelo teclado é mais rápido do que usando o mouse, mas os usuários em geral se acostumaram demais a tirar as mãos do teclado para clicar...
Em relação ao mouse, defendo sua substituição radical pelo monitor-tablet em quase todas as aplicações (menos games). Quem já teve a oportunidade de usar um Wacom Cintiq sabe que esse é o sistema mais natural e eficiente para manipular coisas na tela. Eu adoraria ter um Tablet PC, e não apenas para rodar Photoshop. Infelizmente, devido a uma questão de economia de escala, o sistema é muito caro.

Outra coisa que não dá muito certo no Mac nem no PC é a dimensão das janelas. No Windows é mais frequente maximizar todas as janelas dos programas, e os defensores do Mac sempre denunciaram esse hábito como evidência do mau design do Windows, porque no Mac não existe um equivalente direto da maximização. No Mac OS, muitos programas só aumentam a janela até o tamanho adequado para comportar o conteúdo exibido. Isso soa muito justo, mas acaba sendo um problema quando cada programador interpreta essa regra de uma maneira diferente. Por exemplo, a versão atual do TextEdit expande a janela para a tela inteira, do mesmo jeito que um programa de Windows; mas o Safari faz coisas estranhas com a janela, e o Finder não consegue se decidir exatamente sobre o que fazer. Dica para a Apple: a experiência sugere que para a visualização por colunas (a mais útil), o melhor é deixar abertas duas janelas, uma ocupando a metade de cima da tela e a outra ocupando a metade de baixo.

Mais uma falha clássica: ao assistir a um arquivo de vídeo ou animação Flash, o screen saver entra na frente caso seu tempo de ativação seja inferior à duração da mídia. Curiosamente, isso nunca acontece ao tocar DVDs. Portanto, não creio que seja tão difícil o sistema ser programado para se comportar corretamente com vídeos que não sejam de DVD. O bizarro é que o bug acontece igualmente no Mac OS e no Windows, embora os programas que tocam vídeo tenham pelo menos 10 anos de existência nas duas plataformas.

Vamos aos ícones. Ainda estamos numa situação em que alguns ícones são representações fiéis dos arquivos, como era pretendido desde a invenção das GUIs, e outros são desenhos genéricos que não esclarecem nada, obrigando o usuário a prestar uma atenção exagerada ao nomeá-los. Para os arquivos criados e manipulados pelo usuário, o melhor seria o ícone ser sempre uma miniatura do arquivo. Mac OS e Windows aprenderam a gerar essa miniatura automaticamente para fotografias, mas o Windows ainda trata a miniatura como uma coisa à parte do ícone. Particularmente, acho estranho que os arquivos .PSD e .AI da Adobe tenham ícones representativos do conteúdo, mas não .EPS, .PDF, .INDD e outros formatos da mesma empresa. Idem para arquivos .TXT, .DOC, .XLS etc. Não resta nenhum motivo técnico razoável para esses arquivos só parecerem o que realmente são no campo de preview da janela de abrir dos aplicativos.

As fontes também precisam de um tratamento mais cuidadoso. Uma lista alfabética de nomes não presta para escolher fontes. Alguns poucos programas sabem gerar o útil preview de fontes no menu, mas a imensa maioria não. Pois isso deveria ser um recurso geral do sistema. Sem previews universais de arquivos e fontes, nenhum sistema mereceria o epíteto de WYSIWYG.

A interface gráfica com mouse, janelas e menus foi recebida entusiasticamente nos anos 80 e 90, em preferência à abstrata linha de comando que só apetece aos especialistas. Mas em algum momento futuro, a interface gráfica deverá também ser reconhecida também como uma solução temporária, a ser superada por um novo paradigma, de operação mais natural e simplificada.
Lamentavelmente, os atuais esforços de desenvolvimento consistem apenas em adicionar acessórios, enfeites e complexidade ao sistema de menus, janelas e ícones. A estagnação conceitual é mascarada pelo novidadeirismo.
A lista de problemas conceituais não solucionados é enorme porque os programadores parecem não reconhecê-los como problemas. Infelizmente, os usuários também não. A maioria acha que computador é desse jeito mesmo: que é normal interagir com um cachorrinho animado idiota, que é normal precisar formatar o disco e reinstalar o sistema a cada seis meses. Acorde! Isso é puro e simples mau design. É preciso exigir muito mais dos programadores. Do contrário, estamos eternamente condenados a lidar com interfaces tão antinaturais quanto uma bicicleta com volante de carro no lugar do guidão.

5 comentários:

  1. adorei esta parte do texto! adorei! muito legal :-)

    ResponderExcluir
  2. Ótimo esse texto, como sempre com observações precisas. Tenho aprendido um bocado lendo este blog.
    Gostaria de fazer uma observação sobre o recurso de salvar um arquivo em tempo real. Acho que, por outro lado, a necessidade de se salvar um arquivo de tempos em tempos nos dá um controle do processo, onde, após uma série de intervenções consideramos que o resultado daquele momento representa um progresso no que estamos fazendo. Isso sempre nós dá a liberdade de experimentar sem maiores preocupações. Qualquer problema é só voltarmos à última versão salva.
    É claro que provavelmente podem ser desenvolvidos recursos onde possamos fixar pontos chave no desenvolvimento de um projeto (provavelmnente eu estou falando de algo que já está disponível na maioria dos programas e eu não percebi) e, também sempre podemos recorrer a dezenas de undos para desfazer alguma barberagem.

    ResponderExcluir
  3. Calma lá... A minha idéia não é abolir o save, mas tirar a resolsabilidade do sabe do usuário.
    O save deve servir como "snapshot",um marcador do estágio de um projeto.
    No meu desenvolvimento de capas de revistas, por exemplo: as sucessivas propostas são nomeadas como versão 0.1, versão 0.2 etc. até chegar na 1.0, que é o arquivo final para a gráfica, e o 1.1, que é uma troca com correções.
    O histórico com as manipulações feitas no arquivo deve ser instantâneo, contínuo e permanente (como no InDesign) e, quem sabe, permitir a manipulação fora da ordem (como no Photoshop). Os saves separados não são necessários se se contar como um recurso de versões interno ao próprio documento, como os Layer Comps do Photoshop.
    Um dos meus programas favoritos é o Stickies, onde você simplesmente abre e digita. Se na vida real não é preciso dar títulos aos Post-Its, na vida virtual também não precisa. O programa Notes do Pocket PC salva o arquivo nomeado com as primeiras palavras do que você escreveu. Outro exemplo é o Nisus Writer, processador de texto que também salva tudo automaticamente sem precisar dar nenhum comando, e também nomeia o arquivo com o começo do texto.

    ResponderExcluir
  4. Ali em cima, escrevi sem olhar para o teclado nem para a tela...
    O certo é "responsabilidade do save":D

    ResponderExcluir
  5. Uma forma interessante de se ter um histórico do que se faz num arquivo é como funcionava o VMS. Cada vez que se mandava salvar um arquivo era gerado um novo arquivo com um número de versão atualizado. Assim, você acabava com vários arquivos tipo documento.txt;1, documento.txt;2, etc.

    No MacOS X isso poderia ser aprimorado com os programas criando bundles ao salvar um arquivo, que, a não ser quando explicitado, sempre abririam a última versão ao ser chamados.

    ResponderExcluir