Direções para o GNOME 3.0

Direções para o GNOME 3.0

Directions for GNOME 3.0
Autor original: Jonathan Roberts
Publicado originalmente no:
lwn.net
Tradução: Roberto Bechtlufft

Na Conferência de Desenvolvedores e Usuários do Gnome, a GUADEC, ocorrida há alguns meses, foi anunciado que teríamos um Gnome 3.0 no futuro, e foram abertas as discussões sobre como realizar essa transição. Desde então, outra reunião de desenvolvedores do Gnome, a User Experience Hackfest, foi realizada para discutir e planejar a modernização da interface. Nos últimos dias surgiram vários posts nos blogs do Planet Gnome discutindo alguns dos acontecimentos dos cinco dias do evento, e eu achei que seria interessante fazer um resumo das idéias sugeridas até agora.

O diário

Talvez a idéia que tenha recebido mais destaque, e que já está recebendo trabalho concreto para se tornar realidade, é uma nova maneira de lidar com o gerenciamento de arquivos no dia-a-dia com base no conceito de diário do OLPC. Federico Mena-Quintero postou em seu blog um relatório da sessão de brainstorming de sua equipe. O que há de errado na maneira como lidamos com o gerenciamento de arquivos hoje? Federico explica:

Consideremos um fluxo de trabalho bastante comum: baixar uma imagem de um site, fazer alterações nela e anexá-la a um email. Ao escolher “salvar imagem como” em seu navegador, ele usará a pasta ~/Downloads ou ~/Desktop como padrão. Ao escolher “arquivo/abrir” no GIMP, o padrão será o último diretório usado pelo GIMP, mesmo que tenha sido dias atrás (agora, aqui na minha máquina, o GIMP procurou pelos arquivos em ~/src/um-diretório-qualquer)… Com isso, o fluxo de trabalho fica todo fragmentado, porque os programas só querem ajudar a si mesmos e não colaboram nem um pouco com o seu fluxo de trabalho.

Os programas acabam contribuindo para que os arquivos sejam espalhados por todo o lado, e não há uma maneira fácil de juntar tudo.

3ca93865

Para resolver o problema, eles partem da premissa de que os humanos são bons em lembrar de quando fazem as coisas: “Comecei a digitar meu trabalho na segunda-feira, porque era para ser entregue na quinta” e “eu te mandei aquela foto há duas semanas, logo após a minha festa de aniversário” foram os exemplos dados. Partindo daí, o argumento é o de que se pudermos apresentar aos usuários uma visão de diário de suas atividades, eles nem precisarão lembrar onde armazenaram seus arquivos, navegando pela linha do tempo até encontrar o que procuram.

O diário não cuidaria apenas dos arquivos criados, mas também dos sites visitados e dos bate-papos via mensageiros instantâneos, oferecendo ainda a chance de escrever comentários sobre as entradas. Um exemplo desse tipo de funcionalidade é a possibilidade de anotar números de recibos. Os outros dois recursos de destaque são a possibilidade de marcar os itens importantes com estrelas, para que fiquem em uma seção separada, e a capacidade de criar arquivos diretamente pelo diário, fazendo com que ele haja como uma espécie de bloco de rascunho.

Além da implementação lançada por Federico como prova de conceito, há outros projetos com idéias semelhantes, como a linha do tempo do Mayanna (um fork do Gimmie) e o gerenciador de arquivos Nemo.

Orientação a tarefas

O próximo post não nasceu na User Experience Hackfest, mas sim na GUADEC, alguns meses atrás. Karl Lattimer defendeu que o fluxo de trabalho centralizado nos aplicativos está errado, e que as pessoas não usam o computador com o intuito de usar um aplicativo específico, mas sim para concluir alguma tarefa. Obviamente, as tarefas são apenas parte de um projeto maior.

Karl disse acreditar que Federico esteja indo na direção certa com o diário, desde que os usuários consigam se lembrar do que fizeram e quando fizeram, mas ele também acredita que é preciso dar aos usuários a capacidade de acompanhar o porquê da realização das tarefas, reunindo metadados sobre elas e montando um quadro das relações que existem entre elas. Ele dá como exemplo um email recebido de um amigo nos pedindo para atualizar um certo arquivo dentro de um prazo. A partir daí, poderíamos puxar o arquivo, o prazo, quem nos enviou e talvez até o que precisa ser feito no arquivo, e todas essas informações seriam inseridas no diário ou em outra interface. É claro que isso traz alguns desafios quanto à implementação, mas caso seja concretizado, isso poderia fornecer uma lista automática de tarefas intimamente ligada a modelos para tarefas realizadas com freqüência, deixando para trás em definitivo a idéia de aplicações e espaços de trabalho estáticos.

Karl sintetiza muito bem suas idéias neste parágrafo:

Para chegarmos lá, temos que inventar algumas coisas bem legais, e a semântica é uma parte disso, organizando os dados pelo que eles são e não por sua localização, especialmente porque o usuário tende a perder o controle na selva dos sistema de arquivo. Os diários e controles de versão formam outra parte da idéia, lembrando do que fizemos e quando, mas os modelos e esquemas também são partes dela, mantendo oculta a noção de um aplicativo por trás das tarefas que queremos realizar.

O ambiente desktop

Nessa edição da hackfest, a equipe tentou esquecer da interface atual do GNOME para se focar no que faz sentido para o usuário. Ironicamente, Vincent Untz decidiu abrir seu post, sobre como sua equipe esqueceu da interface atual do Gnome, fazendo algumas observações sobre ela. Ele identificou quatro tipos de problemas na interface. O primeiro deles é a dificuldade em se encontrar a janela correta pelo applet padrão, especialmente quando você tem várias janelas abertas e uma tela pequena. O segundo, poucas pessoas fazem uso da idéia de espaços de trabalho múltiplos, na maioria das vezes por não saberem que o recurso existe. O terceiro, os menus de aplicativos são uma forma lenta e pouco eficiente de abrir novos aplicativos; alguns usam lançadores e o diálogo de execução de aplicativo para melhorar a situação, mas a maioria não sabe como mexer com essas coisas. Por fim, o painel atual certamente é muito poderoso, mas o poder está sendo desperdiçado com flexibilidade desnecessária como a habilidade de posicionar o painel no meio da tela.

Talvez a proposta mais controversa para solucionar esses problemas até agora seja a de restringir o Gnome a um único painel estático: ao remover um painel, estaríamos poupando um valioso espaço na tela, e com um design confiável poderíamos apelar mais à eficiência dos “cantos quentes”, permitindo ao usuário definir sua presença e lançar um novo “modo de sobreposição de atividades”. A ideía de um painel único não gerou muita preocupação, mas a do painel ser estático, sim: Mathias Hasselmann chamou a idéia de “nonsense do painel estático”, sugerindo que muitos usuários do Gnome, incluindo ele e os usuários do Mac OS e do Windows, caem pesado na personalização do layout dos painéis com lançadores personalizados, e melhorar algo removendo funcionalidades existentes não é uma boa abordagem.

A proposta mais promissora do meu ponto de vista, que parece ser uma mentalidade oriunda do OLPC e que já se disseminou na comunidade do Gnome, é a noção de atividades. Uma atividade é essencialmente o que Karl Lattimer descreveu como um projeto, feito de tarefas individuais, e que muitos usuários do Gnome organizam em espaços de trabalho separados no ambiente atual. No ambiente Gnome atual, diz Vincent, as atividades e os espaços de trabalho são estáticos; um usuário configura oito desktops e fica com eles lá. A proposta dele é a de que as atividades deveriam ser bem mais flexíveis, e se um usuário quiser começar uma nova atividade nós deveríamos ajudá-lo criando um novo desktop (espaço de trabalho) automaticamente.

Para onde seguir?

As equipes do Gnome estão bastante ocupadas preparando um plano para a mudança do Gnome 2.x para o 3.0, e de acordo com os planos atuais, parece que o que seria a versão 2.30 será na verdade a 3.0. Nesse cronograma, o mínimo que podemos esperar é por um Gtk+ reformulado, mas as mudanças pelas quais o usuário pode esperar são bem mais difíceis de prever, já que não há planos para uma completa reinvenção da interface como vimos durante o desenvolvimento do KDE 4. Pelo contrário, a equipe do Gnome pretende se manter fiel aos princípios atuais no que diz respeito aos recursos que serão parte do núcleo do desktop: a adoção por distros populares, a estabilidade e um histórico de qualidade serão necessários para que os recursos sejam integrados. Pode parecer que isso impede a inovação, mas há muitos frameworks no Gnome que são muito empolgantes (PolicyKit, PackageKit, Clutter, GVFS, a pesquisa no desktop, D-Conf, o desktop online), e talvez o ciclo de desenvolvimento da versão 3.0 contenha versões maduras dessas tecnologias e cumpra a promessa de revolucionar a experiência de usuário, com muitas dessas tecnologias formando a espinha dorsal das idéias discutidas neste artigo.

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

Sobre o Autor

Redes Sociais:

Deixe seu comentário

X