Ubuntu discute mudanças na usabilidade

Ubuntu discute mudanças na usabilidade

Ubuntu debates usability changes
Autor original: Bruce Byfield
Publicado originalmente no:
lwn.net
Tradução: Roberto Bechtlufft

Desde junho do ano passado, quando Mark Shuttleworth conclamou o Ubuntu a superar o Mac OS X em design nos desktops dentro de dois anos, as listas de discussão e blogs do Ubuntu se tornaram parada obrigatória para debates detalhados sobre a usabilidade no GNU/Linux. Mas quando os desenvolvedores começam a debater a lógica dos princípios do design, a discussão podem se tornar um tanto complicada e acalorada. Um exemplo disso é a discussão sobre as novas diretrizes para notificações na lista ubuntu-devel nas últimas semanas, que rapidamente se transformou em uma discussão acerca do uso ou não de notificações no Linux.

A discussão está focada nas novas diretrizes para mensagens de notificação, que normalmente são exibidas na área de notificação do GNOME. Essas diretrizes foram anunciadas em um post de 21 de fevereiro no blog de Mark Shuttleworth. Tanto o blog quanto as diretrizes incluem fotos da tela ilustrando aquilo que descrevem.

O problema é que as bolhas de notificação (assim chamadas devido à forma que têm) que são o padrão hoje geralmente passam despercebidas porque desaparecem após poucos segundos, e muitas vezes apontam para ícones na bandeja do sistema em que muitos usuários têm dificuldades em clicar. Por esses motivos, as diretrizes orientam uma redução em seu uso, embora admitam a possibilidade de que elas ainda possam ser úteis em circunstâncias não especificadas.

ubuntu-notification

Sempre que possível, na próxima versão do Ubuntu as bolhas de notificação serão substituídas por uma notificação em uma janela já existente; por exemplo, quando um navegador web bloquear um popup, a notificação poderia ser exibida em uma janela sobre a página web dentro do navegador, usando o sistema de notificação integrado do próprio navegador. Numa saída mais radical, se uma notificação depender de um comando do usuário, mas não precisar de uma resposta imediata – quando uma impressora é detectada mas falta o driver necessário, por exemplo – ela será exibida em uma caixa de alerta que abre ao lado da bandeja do sistema sem roubar o foco da janela atual do usuário.

No caso de uma bateria fraca, quando é preciso responder rapidamente, a janela ou caixa de alerta exibirá uma mensagem básica, e quando o usuário clicar nela surgirá uma janela, possivelmente com uma cor de fundo diferente. As diretrizes definem esse processo como “morphing” (transformação), e sugerem que ele ajudará a impedir que um botão seja pressionado acidentalmente quando o cursor se mover para a janela. Os motivos para que a seleção acidental seja vista como um problema, porém, não foram especificados.

A vantagem das caixas de alerta que foram propostas é que, ao contrário das bolhas de notificação, ele permanecem no desktop e oferecem janelas que são mais fáceis de clicar do que um ícone na bandeja do sistema.

As discussões sobre as novas diretrizes começaram logo após o post no blog de Shuttleworth, e passaram por vários tópicos na lista de desenvolvimento do Ubuntu em fevereiro e março. Houve momentos em que foram exigidas explicações que ratificassem certas afirmações sobre a usabilidade, como quando Jordan Mantha disse a Mat Tomaszewski, da equipe de design da Canonical, grupo responsável pelas diretrizes, que frases do tipo “‘confiem em nós, temos nossos próprios motivos’ não vão convencer muita gente.”

A discussão foi adiante, e logo ficou claro que pelo menos alguns designers do Ubuntu que não pertencem à Canonical não confiam nos designer contratados pela empresa. Scott Kitterman, por exemplo, comentou:

A sensação que tenha quando leio os emails e as discussões via IRC das pessoas envolvidas na [equipe de experiência no desktop da]Canonical é a de que eles estão tão convencidos da correção de seu design que qualquer discordância quanto a ele só pode ter se originado da falta de entendimento da comunidade.

De maneira semelhante, Martin Owens reclamou que “é como se as pessoas da Canonical tivessem tomando um rumo político e decidido alienar deliberadamente as pessoas que não são parte da empresa.”

Diante desses comentários, Mat Tomaszewski respondeu diversas vezes, com paciência e entusiasmo diante das tarefas a cumprir, enquanto Matthew Paul Thomas, outro empregado da Canonical, explicou em tom semelhante que os esforços de usabilidade estavam apenas começando, e eram caros o suficiente para que “na maior parte do tempo seja preciso confiar no bom senso”.

Num certo ponto as coisas esquentaram tanto que Mark Shuttleworth interveio dizendo que os comentários de um desenvolvedor “não foram construtivos” – uma ocorrência rara nas listas do Ubuntu comparada às de outros projetos, por causa do código de conduta que os desenvolvedores aceitam seguir.

Mas na maior parte do tempo, a discussão se manteve civilizada. Matthew Paul Thomas defendeu as novas diretrizes, destacando que:

[A] Um ícone de 22×22 pixels na “área de notificação” jamais vai transmitir a idéia de que existam atualizações de software para uma grande parcela dos usuários, mesmo que o designer dos ícones seja muito bom. A frase ‘Há atualizações de software disponíveis para este computador’ pode surtir um efeito bem melhor.

Thomas também listou problemas em potencial das bolhas de informações: ou elas desaparecem após poucos segundos e os usuários não as notam ou elas continuam na tela e distraem os usuários. Além disso, os alertas e janelas são mais fáceis de usar do que ícones pequenos e geralmente incompreensíveis.

Por outro lado, Lars Wirzenius apresentou argumentos contra todas as notificações, afirmando que:

As notificações sempre são interrupções. Quando aparece algo novo na tela, interrompe os meus pensamentos e o meu trabalho, e se eu estiver ‘em transe’ (também conhecido como ‘modo hacker’), essa interrupção pode custar uns quinze minutos de tempo de trabalho efetivo.

Wirzenius queria apenas notificações essenciais, sugerindo: “Na minha opinião, todos os aplicativos deveriam tentar interromper o usuário o menos possível, principalmente por padrão.”

A posição de Wirzenius logo foi contestada por outros desenvolvedores de maneiras que mostram que algumas coisas devem ser levadas em consideração no design da usabilidade. Chow Loong Jin questionou a afirmação de Wirzenius de que as configurações padrão devam ser criadas para aqueles que usam o computador como “ferramenta” e não como um “brinquedo”, argumentando que os usuários de “ferramentas” saberiam mudar as configurações padrão, ao contrário do segundo tipo.

Ted Gould defendeu que as configurações padrão devem ser voltadas para os usuários que vêem o computador como um brinquedo, já que eles são maioria. No mesmo post, ele sugere que:

A realidade é que nós desejamos níveis diferentes de notificações em momentos diferentes. Por vezes uma interrupção não faz mal, por outras faz. Por exemplo, quando um conhecido pergunta pelo instant messenger se você não quer ‘dar uma esticadinha na hora do almoço’ no meio da apresentação que você está fazendo para o chefe. O problema é que é difícil detectar as intenções das pessoas.

Mas Tomaszewski indicou que uma certa capacidade de alteração nos níveis de notificação seria possível por meio de um modo “Não perturbe” que bloquearia ao menos as notificações comuns.

O que tornou a discussão especialmente interessante foi a forma como ela trouxe à tona tanto as questões gerais quanto às específicas da usabilidade. Por exemplo, Mathew Paul Thomas respondeu à sugestão de que o uso de um aplicativo em tela cheia deveria desativar as notificações explicando que:

Se você estiver usando o Ubuntu em um netbook, por exemplo, provavelmente vai usar os aplicativos em tela cheia sempre que puder, sem que isso tenha coisa alguma a ver com as bolhas de notificação que deseja ver.

Thomas também avisou que:

Os desenvolvedores geralmente acham que o software que fazem é mais fascinante para as pessoas do que ele realmente é, o que faz com que eles tornem o software mais ‘falador’ do que deveria ser (o extremo patológico disso pode ser encontrado nas diretrizes de experiência de usuário do Windows Vista, que recomendam seriamente que um ‘evento que não seja crítico ao sistema’ deve exibir um balão de notificação ‘uma vez a cada dez minutos se os usuário tiverem que resolver a situação em uma hora, e uma vez por hora se os usuários tiverem que agir em um dia’).

De maneira semelhante, Tomaszewski afirmou que:

Temos bons motivos para acreditar que indicadores persistentes funcionam apenas em casos bem específicos (como conexões de rede, volume etc). Agora estamos passando pelo longo e doloroso processo de definir cuidadosamente esses casos.

Bruce Cowan resumiu em outro post os problemas de qualquer tipo de janela. O súbito surgimento de janelas e alertas, sugeriu Cowan, confunde e pode fazer os usuário temerem que um tipo de malware tenha iniciado um aplicativo. Além disso, janelas demais podem deixar o usuário frustrado, ao ponto de alguns as desativarem completamente, de modo que o abuso do sistema pode acabar com todo o propósito das notificações. Quanto às mudanças nas diretrizes, Cowan sugeriu que elas possam incomodar usuários experientes que não vejam grandes problemas nas bolhas de notificação.

É incerto se essas discussões terão ou não algum efeito nas equipes de de design e experiência de desktop do Ubuntu, já que as diretrizes já estão sendo usadas nas versões alpha da próxima versão (Jaunty). Esse é o tipo de discussão que os desenvolvedores do Ubuntu provavelmente continuarão tendo pelos próximos dezoito meses, na tentativa de concretizar a meta estabelecida por Shuttleworth para uma melhor usabilidade, especialmente diante da falta de dados que mostrem que tipos de design oferecem maior usabilidade. E é bem provável que tenham que discutir tudo de novo para que as mudanças sejam aceitas pelo upstream de projetos como o GNOME. Porém, para outros, isso serve para mostrar as considerações minuciosas, porém necessárias, que a usabilidade costuma envolver – considerações que muitos projetos de software de código aberto só agora começam a encarar.

mark

Créditos a Bruce Byfieldlwn.net
Tradução por Roberto Bechtlufft <roberto at bechtranslations.com>

Sobre o Autor

Redes Sociais:

Deixe seu comentário

X