Entendendo o Unity

SCALE: Understanding Unity

Autor original: Nathan Willis

Publicado originalmente no: lwn.net

Tradução: Roberto Bechtlufft

No dia 27 de fevereiro, Ted Gould, da Canonical, apresentou na conferência SCALE 9x uma palestra sobre a interface Unity do Ubuntu. Bom, não foi bem uma palestra: Gould passou alguns minutos apresentando o Unity por meio de uma apresentação de slides e descrevendo os objetivos do projeto, mas reservou uns quarenta minutos para responder às perguntas do público. Foi uma excelente ideia: o público não parou de fazer perguntas sobre o design do Unity, seus recursos, o lugar que ocupa na pilha do desktop, as diferenças em relação ao GNOME Shell e a implantação no Ubuntu. Para um projeto de alta visibilidade que já existe há quase duas versões da distro, parece haver bastante confusão entre os usuários. Até certo ponto isso parece comum em todas as recriações de interfaces, e o GNOME Shell passa pela mesma situação (que já foi encarada também pelo KDE 4).

Desvendando o básico do Unity

A palestra de Gould foi intitulada “Unity: que importância ele tem?”, e começou com um resumo dos objetivos do projeto. Segundo Gould, o Unity começou como uma tentativa de integrar de forma mais direta um design com “habilidades sociais” como psicologia, sociologia e arte ao processo de desenvolvimento de software. Esse é o paradigma de design centrado no usuário, que historicamente não é a forma como o software de código aberto foi se desenvolvendo. Na maioria das vezes, o código aberto atende aos valores que importam aos entusiastas (superioridade técnica, capacidade de personalização, poder e liberdade), mas fica para trás em outros valores importantes para “todo o resto”, como a previsibilidade, a capacidade de descoberta e o visual de modo geral.

Ted Gould na SCALE 9x (2011)

As principais mudanças no design do Unity vêm de testes de usabilidade realizados a cada seis meses nos escritórios da Canonical em Londres. Nos testes, pede-se a voluntários que realizem tarefas comuns que desempenhem no dia a dia no computador. Essas pessoas são observadas e passam por uma entrevista onde contam sua experiência. Gould citou um exemplo: pessoas que afirmavam passar bastante tempo subindo fotos pessoais para o Facebook recebiam a tarefa de fazer essa mesma atividade na máquina de testes. Ele acrescentou que é importante que desenvolvedores e projetistas estejam presentes nessas sessões de testes para conversar com os voluntários e ouvir suas opiniões, em vez de apenas assistir ao vídeo do teste ou ler os resultados quantitativos.

A maior mudança no Unity é a redefinição da maneira como o painel superior funciona. Os usuários mostraram-se reticentes em clicar em ícones e menus nesse painel porque, ao longo dos anos, o Windows e o Linux passaram a agrupar todo tipo de função nesse espaço: menus que abrem opções adicionais quando clicados, botões que realizam ações, efeitos visuais desnecessários e por aí vai. O Unity implementa uma política rígida de uso exclusivo para funcionalidade de menus, no que chama de indicadores de aplicativos. Qualquer aplicativo pode colocar um indicador no menu, mas clicar no indicador não realiza ações; o clique pode apenas revelar um menu suspenso.

A segunda parte do sistema é o painel do lançador no lado esquerdo, que como muitas outras interfaces de docking, abriga botões grandes para lançar aplicativos favoritos, ícones para os aplicativos que já estão em execução e atalhos para o gerenciador de arquivos, o navegador de aplicativos, a lixeira e o alternador de espaço de trabalho. Aqui o Unity também implementa uma política rígida de exibição, agrupando todas as janelas de um mesmo aplicativo em um único ícone, permitindo reorganização por meio de arrastar e soltar apenas para o segmento do lançador de aplicativos e apresentando uma API que os desenvolvedores podem usar para incluir funções via clique direito.

O Unity também apresenta um navegador de aplicativos pesquisável ao estilo “lista rápida”, e não um menu à base de texto. A apresentação visual é quase idêntica à do GNOME Shell (incluindo as categorias), mas o Unity usa o Zeitgeist no back-end para pesquisar os aplicativos usados recentemente e as descrições completas dos arquivos .desktopdos aplicativos, não se limitando ao nome curto. Além disso, assim como o GNOME Shell, o Unity agrupa diversas funções comuns, incluindo o mensageiro instantâneo e as opções de presença, em um “menu de usuário”. Ao contrário do GNOME Shell, o Unity usa um “menu de sistema” separado para tarefas de manutenção e funções de desligamento e reinício. Por fim, o Unity preserva o recurso de espaços de trabalho/desktops virtuais múltiplos que veio mesmo para ficar nos desktops, mas acrescenta um efeito de aumento/redução de zoom que, segundo Gould, deixa as pessoas que usam o sistema pela primeira vez menos confusas, com base nos resultados dos testes.

O Unity em si é um plugin para o gerenciador de janelas Compiz, e depende de funcionalidade existente no Compiz (ou em outros plugins) para o empilhamento de janelas, o foco e os efeitos de transição. Embora afirme que um dos objetivos de design era o de tornar o Unity “lindo”, Gould disse que o Ubuntu encara o Unity como a “moldura do quadro”, visando a dar ênfase aos aplicativos, e não ao ambiente de desktop em si. O programa da Canonical para a integração entre testes e design no processo de desenvolvimento almeja, segundo ele, inspirar outros projetos a adotarem uma abordagem parecida, e espera tirar proveito das novas APIs de indicadores e lançadores.

Algumas perguntas importantes

Depois que a visão geral do Unity foi apresentada, começaram as perguntas do público. Elas se enquadravam em duas categorias principais: perguntas relacionadas à implementação técnica do Unity e perguntas sobre as alterações que ele trazia ao fluxo de trabalho dos usuários em comparação ao painel do GNOME 2.x.

Na primeira categoria, ficou claro que muitos usuários pensavam que o Unity implementava um novo gerenciador de janelas, ou que substituía partes essenciais da pilha de desktop do GNOME além do painel. Por exemplo, um dos participantes achava que o Unity acabaria com a capacidade de salvar arquivos no desktop, ou de acrescentar atalhos para aplicativos nele. Gould explicou que o Unity nem tocava no desktop, que ficava por conta do Nautilus como ocorre hoje.

Várias pessoas perguntaram sobre recursos de personalização, incluindo a possibilidade de mudar o tema, redimensionar ou mover a barra de menu e o lançador. Gould explicou que a cor de fundo, os ícones e as fontes usadas são herdadas do tema do GTK+ do usuário, e que seguem as escolhas personalizadas realizadas pelo usuário no que tange às configurações de acessibilidade, como cores de alto contraste ou fontes de tamanhos maiores. Os indicadores de aplicativos são ícones “simbólicos”, de uma cor só, mas a barra de menus tenta determinar se a cor de fundo é clara ou escura para escolher a cor mais apropriada ao ícone. O tamanho da barra de menus e dos lançadores não pode ser alterado na versão atual, segundo ele, mas já há um patch sendo desenvolvido para isso. Também há um patch sendo criado para permitir a movimentação do lançador para o lado direito da tela, um recurso solicitado por usuários de idiomas escritos da direita para a esquerda.

Outras pessoas perguntaram sobre a personalização de recursos de gerenciamento de janelas, como o comportamento de foco, o empilhamento de janelas e coisas do gênero. Gould explicou várias vezes que o Unity é um plugin para o Compiz, e que depende de recursos existentes no Compiz para esse tipo de coisa. Segundo ele, se você tiver um plugin para animar o fechamento de janelas usando chamas renderizadas via OpenGL, isso vai funcionar no Unity também. Por padrão, porém, a versão do Compiz do Ubuntu vai trazer apenas um conjunto básico de plugins do Compiz, sendo que os usuários podem instalar outros que interfiram com a forma como o Unity trabalha. Seguindo o mesmo princípio, o Unity não tem função própria para exibir miniaturas das janelas abertas, pois o Compiz já tem uma função para isso.

Foram feitas várias perguntas sobre como acessar aplicativos que não estejam posicionados no lançador. A apresentação de slides de Gould apresentou a função de pesquisa via Zeitgeist, que para muitas pessoas significava que não haveria função de navegação (quando na verdade há), e que a única maneira de se encontrar um aplicativo seria pesquisando por seu nome. Essa confusão poderia ter sido evitada se o botão “Aplicativos” estivesse em destaque no lançador durante a apresentação.

Muita gente pensava que pesquisar por aplicativos pelo nome era mais lento do que usar o menu de aplicativos do GNOME 2, especialmente quando a pessoa já sabia onde estava o aplicativo. Uma pessoa disse que, historicamente, os “docks” como o lançador do Unity eram usados apenas para os favoritos, e perguntou se havia algum benefício na remoção do menu de aplicativos. Gould respondeu que o menu de aplicativos do GNOME 2.x tinha problemas com o uso de categorias genéricas demais, como “Internet”, e que nos testes, os usuários geralmente sabiam o nome do aplicativo que queriam usar, mas não sabiam onde esse aplicativo estava entre as categorias. Logo, apertar o botão de pesquisa e digitar o nome do aplicativo é mais rápido do que navegar por um menu de lançadores de aplicativos. Além disso, ele também acrescentou que o recurso de pesquisa retorna resultados baseados não apenas no nome dos aplicativos, mas na descrição longa presente em seus arquivos .desktop, tornando possível restringir uma consulta ainda mais do que seria possível apenas com o uso de categorias.

As perguntas sobre o fluxo de trabalho dos usuários já penderam mais para questões pessoais. Uma das presentes se mostrou preocupada com a falta de applets para o painel nos moldes dos que existem para o GNOME 2.x, já que prefere usá-los para acesso rápido a tarefas como tirar fotos. Gould respondeu que ela poderia adicionar o mesmo aplicativo ao lançador do Unity, e para maior comodidade, movê-lo para o fim da lista de botões, para longe dos lançadores de “favoritos” e mais próximo dos botões de espaço de trabalho e aplicativos.

Uma pessoa que instala Linux para recém-convertidos, perguntou como seria a atribuição de nomes alternativos para os aplicativos (como rotular o Abiword ou o OpenOffice Writer como “Word”), e outra perguntou sobre categorias de aplicativos personalizadas. Gould respondeu que não havia um recurso interno para fazer essas coisas, mas que como o recurso de pesquisa faz a indexação de arquivos .desktop, incluir nomes alternativos ou categorias adicionais no arquivo .desktopdaria o mesmo resultado.

Para concluir, muitos achavam que a versão 11.04 do Ubuntu, que trará o Unity, obrigaria os usuários a migrarem para ele. Gould disse que haverá uma opção na hora do login, e que os usuários podem usar os painéis no estilo do 2.x se preferirem.

Mudanças

Depois da palestra, eu perguntei a Gould o que ele tinha achado da sessão de perguntas e respostas. Ele se mostrou surpreso com algumas das perguntas, a maioria referente ao uso da pesquisa e do lançador de aplicativos no lugar do menu, dizendo ter pensado que o Google já havia condicionado todo mundo a ter que pesquisar para acessar conteúdo por padrão. Ele também acredita que mudanças na interface sempre sejam encaradas com alguma preocupação, porque têm potencial para causar perturbações em padrões confortáveis e que já funcionam.

Dá para notar isso claramente nas perguntas feitas sobre o fluxo de trabalho. A maioria delas tratava da preocupação de que a nova interface pudesse deixar tarefas comuns e repetitivas mais lentas. O GNOME Shell, que adota muitos dos mesmos recursos implantados no Unity, também gera o mesmo tipo de preocupação. Em ambos os casos, vale dizer que é muito raro uma nova interface remover funcionalidades que já existiam. Geralmente ela só muda a localização desses recursos. Parece que essa é uma área onde os dois projetos podem investir mais.

Os recursos do painel do GNOME 2.x, por exemplo, foram divididos em duas partes no Unity. Alguns applets que já se comportam mais como menus (como o Tomboy), podem usar facilmente a API do indicador de aplicativos para apresentar a mesma funcionalidade. Outros, que têm comportamento semelhante ao de botões (como o aplicativo para tirar fotos), podem oferecer a mesma funcionalidade no lançador. Embora Gould não tenha dito isso explicitamente, a ideia de abrir-a-pesquisa-digitar-o-nome-do-aplicativo parece seguir o mesmo paradigma do GNOME Do. As respostas dadas por Gould parecem ter acalmado o público. Talvez esse tipo de comparação ponto a ponto devesse ser o padrão nas documentações introdutórias do Unity e do GNOME Shell.

Por outro lado, parece que a Canonical ainda não conseguiu deixar claro em quais partes da experiência do desktop GNOME o Unity mexe e em quais não mexe, e não há nenhuma solução simples para esse problema. As pessoas se mostraram confusas quanto às alterações no desktop, ao comportamento do gerenciador de janelas, à bagagem herdada do GTK+ e a outras funções de base. Talvez isso se deva em parte ao vocabulário usado, fazendo referência ao Unity como um “ambiente”, e não como um painel e um lançador. Mas também pode ser pelo fato do Unity ter nascido da edição para netbooks do Ubuntu, o que dá a impressão de um ambiente com menos recursos. É só vermos o artigo da Wikipédia sobre o Unity, que destaca seu “uso eficiente do espaço” no primeiro parágrafo, e o contrasta com o ambiente GNOME “completo”. Não que eu ache que a Wikipédia tem credencial de autoridade, mas ela é uma boa fonte de avaliação das opiniões das massas.

Como o software de código aberto é quase sempre desenvolvido por equipes remotas (no caso da Canonical, muitas vezes trabalhando em casa), talvez ele sempre vá ter dificuldades para introduzir novos recursos de grande porte. A maior parte do que Gould explicou em suas respostas já está documentado em outros lugares na Web, seja em uma página de wiki ou em posts de blogs sindicados pelo Planet Ubuntu, e mesmo os usuários interessados ao ponto de passar o fim de semana na SCALE tinham lá suas dúvidas e percepções equivocadas sobre o Unity. O GNOME organizou um “dia do usuário” via IRC recentemente, onde desenvolvedores e projetistas se encontraram para responder a perguntas sobre o GNOME 3.0 e o GNOME Shell, e a experiência foi parecida: até usuários experientes o bastante para se sentirem confortáveis usando o IRC apresentaram um monte de perguntas.

É sempre esclarecedor quando os desenvolvedores interagem cara a cara com os usuários finais, e esse é um dos maiores favores prestados por eventos comunitários como o SCALE. Acho que a mensagem que fica para a equipe do Unity é que as pessoas ainda não entenderam direito o que é o Unity e o que ele faz. Como resolver esse problema é que não está muito claro ainda. Se você tiver uma boa solução, garanto que vai lotar uma sala na SCALE ou em qualquer outro evento de software de código aberto.

Nota: tela do Unity no Ubuntu Netbook Edition 10.10

Créditos a Nathan Willis – lwn.net

Tradução por Roberto Bechtlufft <info at bechtranslations.com.br>