Gnome Files: uma análise detalhada da UI
(datagubbe.se)- Trata-se de uma crítica de que, no processo de usar o Gnome Files para organizar arquivos de verdade, operações básicas como alternar a visualização, inserir caminhos, ajuda, tooltips e mover a janela acabam confundindo o usuário
- O menu suspenso “View Options” na prática mostra opções de ordenação, enquanto a troca de visualização fica escondida em outra área de um split button, criando um desencontro entre nome e disposição das funções
- A barra de caminho parece permitir entrada de texto, mas não pode ser editada com o mouse e só é ativada pelo atalho Ctrl-L, reduzindo a capacidade de descoberta da função na GUI
- A área superior sem barra de título faz com que cliques em botões, arrasto da janela e menu de contexto se sobreponham no comportamento, e a barra de rolagem oculta também muda de posição quando o ponteiro passa por cima, tornando incertas operações básicas
- O novo paradigma de UI não produziu resultados melhores do que padrões já comprovados, como barra de menus, barra de título e exibição consistente de atalhos, e o modo antigo não é automaticamente ruim
Por que escolher o Gnome Files e quais são as premissas
- O foco da crítica não é o flat design em si, mas a forma de acessar funções centrais do programa
- Reconhece-se que um design moderno pode ser mais amigável para iniciantes, mas power users que passam várias horas por dia no computador também devem ser considerados no projeto
- Quanto mais a interface esconde funções, mais fácil é que o usuário perca a chance de descobri-las e aprendê-las
- O Gnome costuma ser o ambiente de desktop padrão em várias distribuições Linux importantes e defende publicamente direções como “usable by everyone”, “structurally and aesthetically elegant”, “distraction free” e “traditional desktop is dead”
- O Gnome Files é um gerenciador de arquivos, elemento central do ambiente de desktop, então é um caso importante para observar a filosofia de UI do Gnome
Problemas de estrutura de menu revelados na troca para visualização em lista
- A primeira impressão é considerada limpa e tranquila, e os elementos clicáveis também são distinguíveis até certo ponto
- Os problemas começam ao tentar trocar os ícones grandes pela visualização em lista
- Na barra de ferramentas há ícones com aparência parecida, e o menu suspenso com tooltip “View Options” não mostra opções de visualização, mas sim várias opções de ordenação
- Opções realmente ligadas à visualização, como “Icon Size” e “Show Hidden Files”, ficam no “Main Menu”, criando um descompasso entre o nome “View Options” e sua composição real
- A troca para visualização em lista não faz parte do menu suspenso “View Options”, e sim da área de alternância de um split button
- Como a função de alternância não aparece listada junto no menu suspenso, não fica claro por que ambas estão agrupadas no mesmo widget
- Por causa dessa estrutura, levou tempo para encontrar o controle de visualização em lista, e isso gerou mais frustração do que elegância estrutural
Problemas de descoberta em ajuda e tooltips
- Mesmo buscando “list view” na ajuda embutida, é difícil encontrar de imediato como ativar a visualização em lista
- Apesar de a ajuda ter sido aberta pelo menu do Gnome Files, os resultados de busca também exibem itens relacionados a outros aplicativos
- “Browse files and folders” estava relacionado ao Gnome Files, mas aparecia depois de itens como “Manage volumes and partitions” e “Edit contact details”
- Ao navegar manualmente pela ajuda, o item encontrado sobre “List View” tratava do que fazer depois que a visualização em lista já estivesse selecionada
- Tooltips podem ser úteis, mas no Gnome Help e no Gnome Files tooltips desnecessários acabam mais atrapalhando do que ajudando
- No Gnome Help, um tooltip com o mesmo texto do título do item cobre o título do item seguinte
- Na barra lateral esquerda do Gnome Files, itens como “Recent” e “Starred” também exibem tooltips óbvios
- Esse comportamento pode levar o usuário a aprender que tooltips não trazem informação útil, e sim distração
Navegação por caminho e exposição de funções centradas em atalhos
- A navegação em si no Gnome Files é considerada em geral aceitável, mas sente-se falta de um botão de diretório pai para subir um nível
- Os botões de voltar/avançar apenas percorrem o histórico de navegação e não são equivalentes a ir para a pasta superior
- É possível navegar clicando no nome do diretório na barra de localização, mas isso é menos prático e mais sujeito a cliques errados do que um botão para pasta pai
- A barra de localização parece uma caixa de texto, mas não é possível ativar o modo normal de edição com o mouse
- O modo de edição aparentemente só é ativado pelo atalho Ctrl-L
- A impressão inicial foi de que a função nem existia, e ela só foi descoberta por busca; o atalho aparece na janela de atalhos de teclado
- Quando um elemento da GUI não pode ser acessado com o mouse, sua descoberta fica prejudicada
Limites da janela de atalhos e da substituição da barra de menus
- A lista de atalhos tem 3 páginas e até possui busca, mas é difícil usá-la se a pessoa não souber o que procurar
- O Gnome Help chama a barra de localização de “path bar”, mas ao buscar “path” na janela de atalhos não aparece resultado algum
- A lista de atalhos não oferece sumário nem uma forma rápida de percorrer categorias, exigindo verificar as páginas uma por uma
- Existe até um atalho para abrir a janela de Keyboard Shortcuts, mas, ao contrário de alguns outros atalhos, ele não é mostrado ao lado do item correspondente no Main Menu
- A barra de menus tradicional categoriza as funções do programa, mantém tudo visível, mostra atalhos de forma consistente e permite executar imediatamente as opções encontradas
- No Gnome Files, as funções ficam espalhadas pela UI e algumas funções escondidas só podem ser aprendidas por meio de uma janela modal de atalhos
- A janela de atalhos é não interativa e modal, então não dá para deixá-la aberta enquanto se experimenta
- O usuário precisa encontrar o atalho, memorizá-lo, fechar a janela e só então executar a função
- Em um ambiente centrado no mouse, não haver uma forma gráfica de encontrar e executar funções torna a experiência limitada e confusa
Ambiguidade da UI superior sem barra de título
- O Gnome Files não tem uma barra de título real, então a janela é movida clicando e arrastando a área superior
- Essa área superior também contém a barra de ferramentas, de modo que é possível mover a janela mesmo começando o clique em controles da UI que já têm outra função
- É possível clicar no ícone de busca para abrir a pesquisa, mas também clicar e arrastar esse mesmo ícone para mover a janela
- Os botões de voltar/avançar podem abrir o histórico de localização com clique de contexto ou long click, mas nada no botão indica essa função
- Também não parece haver atalho para esse recurso
- Fazer long click em outros itens não abre menu de contexto, então o comportamento não é consistente
- Para trazer a janela para frente, é preciso encontrar uma área não clicável que não acione funções do programa
- É necessário evitar cliques acidentais que iniciem busca, navegação por caminho, troca de visualização ou acesso a outras funções
- Até uma simples ativação da janela exige atenção do usuário, aumentando a carga cognitiva
- Ao clicar com o botão direito na área superior, aparece um menu de gerenciamento da janela ou um menu de operações do diretório, dependendo da posição, do diretório atual e do ponto clicado
- O clique do meio pode abrir em nova aba nomes de diretórios, incluindo o diretório atual, e essa função também existe no menu de contexto
Barras de rolagem ocultas e comportamento do tema padrão
- O Gnome Files ou o GTK 4 usa barras de rolagem ocultas
- O comportamento foi observado com as configurações padrão e com o tema GTK 4 padrão fornecido pelo Debian
- Barras de rolagem ocultas escondem não só a possibilidade de interação, mas também a informação de onde a pessoa está na lista de arquivos ou no documento
- Ao mover o mouse, a barra de rolagem aparece, mas foi considerada pequena e com baixo contraste, o que dificulta enxergá-la
- Quando o ponteiro passa sobre a barra, ela aumenta e fica mais visível, mas se desloca para a esquerda na mesma medida da largura original, fazendo com que o ponteiro deixe de ficar sobre ela
Avaliação geral e conclusão
- A UI do Gnome Files é avaliada como haphazard, incoherent e às vezes até perigosa
- Os principais problemas são os seguintes
- Nomes de menu e conteúdo não correspondem, e as opções reais de visualização ficam espalhadas em vários lugares
- Atalhos não são mostrados de forma consistente nos menus
- Algumas funções comuns só podem ser acessadas e descobertas por atalho
- A aparência dos widgets não antecipa corretamente seu comportamento
- Tooltips induzem erro ou atrapalham sem agregar valor informativo
- Mover a janela clicando em ícones de função aumenta o risco de clique errado
- O resultado do clique de contexto na área superior é difícil de prever
- A barra de rolagem do tema padrão muda de posição quando o ponteiro passa por cima
- A terminologia da ajuda e da GUI não coincide
- Essas inconsistências dificultam que o usuário forme um modelo mental estável da UI
- Em termos funcionais, o Gnome Files permite gerenciar arquivos e, na falta de alternativas, talvez seja possível se acostumar com suas características de UI
- Ainda assim, mesmo em um aplicativo central como o Gnome Files, há muitos elementos que podem ser considerados ruins sob a ótica de projeto de interface
- Isso não significa que o paradigma antigo de desktop, nem todos os programas tradicionais, fossem perfeitos, mas permanece a questão de que um novo paradigma deveria produzir resultados melhores
- Já existem soluções refinadas há décadas para a maior parte dos problemas apontados
- Uma barra de título de janela real
- Exibição consistente de atalhos nos menus
- Categorização consistente de menus e opções
- Uma linguagem de design mais rica
- O modo antigo não é automaticamente pior, e o novo também não é automaticamente melhor
1 comentários
Opiniões no Hacker News
Lembro do problema de, na visualização em lista do Files, só ser permitido clicar com o botão direito em um espaço vazio para criar um novo documento ou colar
Na visualização em lista, se houver só um pouco mais de arquivos e a janela ficar cheia, desaparece o espaço vazio onde clicar
Já havia pessoas que enfrentaram o mesmo problema antes 0, e parece que ainda não foi corrigido direito 1
Fui pesquisar e, no Thunar, se você mantiver
Ctrlpressionado e clicar com o botão direito em qualquer lugar, aparece um menu com opções como criar nova pasta, colar e abrir no terminalPorém, se um arquivo estiver selecionado, aparece o menu de contexto do item selecionado e a opção de nova pasta não aparece; no fim, ainda é preciso clicar em um espaço vazio para desfazer a seleção ou saber usar
Escape, então não é o idealO tile inteiro da matéria, o texto do link, a imagem e até as margens largas viram link, e só a fenda estreita entre os tiles pode ser clicada como fundo
Se for um design voltado primeiro para toque, dá para entender, mas em softwares de desktop como o GNOME parece que um objetivo semelhante acabou se infiltrando ao tentar atender vários métodos de entrada ao mesmo tempo
Na issue vinculada há uma imagem mostrando as áreas em que é possível clicar com o botão direito
https://gitlab.gnome.org/-/project/1/uploads/50ac36ab40f9049f4a823f77aa9a8a29/gr-files-right-click-zones.jpg
Então subo para a pasta pai até encontrar uma pasta que não esteja lotada, abro o Terminal ali e depois desço de novo com
cdaté a pasta originalUm menu de contexto deve mostrar ações que podem ser aplicadas ao objeto clicado com o botão direito, e “novo documento” não é uma função do ícone de um arquivo ou pasta
Também fica ambíguo se, ao clicar com o botão direito em uma pasta, o novo documento será criado na pasta atual ou dentro da pasta clicada
Para tarefas comuns assim, é melhor colocá-las como itens de menu em uma barra de ícones sempre visível, separadas do menu de contexto de clique com o botão direito em espaço vazio
É uma crítica razoável, mas mistura incômodos de UI vindos da linguagem de design com falta de polimento nos detalhes
Se olhar o Finder atual do macOS, o design é muito parecido com o GNOME Files: https://a.qoid.us/20240907-finder.png
Portanto, desvantagens do próprio design, como ser difícil arrastar a janela ou clicar nela para ativá-la, também existem no Finder
Mas o macOS evita a maior parte dos problemas de detalhe apontados pelo autor
As opções de visualização têm ícones parecidos, mas no Finder a pequena seta à direita do ícone também é sempre parte do mesmo botão, e ele não usa o tipo de botão dividido do qual o autor reclamou
Quanto à ajuda, o macOS User Guide explica o significado dos ícones e, ao digitar na Help, ela pesquisa e mostra itens de todos os menus
Se você digitar “list”, aparece o item de menu “as List”, permitindo executar a ação desejada
Tooltips não aparecem na lista de locais à esquerda, apenas nos ícones da barra de ferramentas, e mesmo assim demoram a surgir
Na navegação, o Finder praticamente não tem uma barra de localização, a caixa de diálogo para abrir por caminho também fica escondida, e a ação de ir para a pasta superior não é muito visível
Ainda assim, não há elementos que pareçam editáveis mas não sejam
As barras de rolagem ficam ocultas por padrão, mas permanecem no lado direito da janela e não saltam para a esquerda como o autor reclamou
Se for difícil acreditar, basta abrir https://macos9.app em um dispositivo com mouse e tentar organizar e navegar por arquivos
Sempre pareceu algo portado de qualquer jeito do NeXTStep e depois rapidamente abandonado
De modo geral, a Apple perdeu o senso de UI ao longo da última década mais ou menos, e o macOS não deve mais ser usado como bom exemplo de UI de desktop
Há um item de menu para ativá-la
É engraçado que haja gente que acredita no marketing da Apple de que seu sistema operacional é o mais ergonômico
Até criar uma nova pasta vira um pesadelo: se você tentar criar uma pasta ou colar arquivos em algo parecido com uma visualização em árvore, eles acabam indo para a pasta pai de nível mais alto
A ordenação por data recente também não faz sentido
No geral, a ordem é do mais recente para o mais antigo, mas dentro de grupos como uma data específica ou semana passada ela se inverte, indo do mais antigo para o mais recente
Além disso, há centenas de outras decisões estranhas desse tipo
Também é difícil entender por que fizeram a tecla
Entereditar o nome do arquivo em vez de abri-loAcabaram usando uma tecla principal para uma tarefa que quase nunca é feita
O GNOME esconde o Power off em um submenu adicional para impedir que o usuário aperte sem querer, mas no Files coloca Format logo ao lado de “Safely remove drive”
opt, é possível executar o desligamento/reinício imediatamente com dois cliques, sem confirmação, mas no GNOME são quatro cliques e ainda há uma animação esquisitaAmbos enfiam controles demais na barra de título, a ponto de não sobrar espaço para arrastar a janela
Recentemente usei o OS X 10.5 por uma semana em um G4, e acho que aquela foi a era de ouro do desktop
Por exemplo, no menu de dispositivos de armazenamento em massa USB, “Eject” e “Format” aparecem lado a lado
Um é inofensivo, mas o outro é potencialmente destrutivo
Depois de Format há
..., o que significa que uma caixa de diálogo será aberta; essa caixa é um processo em 2 etapas e, no fim, mostra um aviso em vermelho de que todos os dados serão excluídos permanentementeNão há como formatar o dispositivo por acidente
Se quiser desligar rapidamente, basta mudar a ação do botão de energia de suspender para desligar
Foi bom ler um texto assim
Eu também imaginei muitas vezes que gostaria de destrinchar de forma rigorosa esses pequenos problemas irritantes de GUIs e organizar por que elas deveriam melhorar
Ctrl+Lé um atalho estranho se visto sem contexto, mas é uma tecla que eu conheço há 15 anos por usar navegadores, então é familiarO fato de Windows, GNOME e Nautilus compartilharem isso é bom para usuários de longa data ou avançados
Lendo de novo, talvez a reclamação seja menos sobre o atalho em si e mais sobre não haver outro jeito
Um grande problema que o texto não menciona é que a UI atual do GNOME é muito parecida com a do Windows 11, mas estraga muitos detalhes, como tooltips ou uma barra de localização clicável
Usei GNOME no Ubuntu 14.04 e 20.04, mas tive problemas de estabilidade no 22.04; agora uso XFCE com satisfação, e estabilidade de longo prazo é o que há de melhor
Atualmente, clicar na barra já permite entrar direto no modo de edição
O pior da abordagem do GNOME talvez seja a arrogância
Como eles dizem que fazem pesquisa de usabilidade e repetem que focam em usabilidade, quando uma pessoa sente dificuldade para usar, isso acaba sendo duas vezes mais frustrante
Soa como “o usuário médio está satisfeito, então o problema é você”
Se você realmente tiver uma deficiência, por motivos políticos a prioridade de adaptar a UI provavelmente será maior
Às vezes acho engraçado imaginar que, nas profundezas do culto do GNOME, existe uma única pessoa chamada Mother Gnome
A premissa é que ela é legalmente cega, fisicamente incapaz de usar um teclado, pertence simultaneamente a todos os grupos tradicionalmente sub-representados entre usuários de computador, nunca usou um computador e aprendeu algumas coisas de iPhone com uma sobrinha-bisneta da geração Alpha
A soma de todos esses fatores a transforma em um monstro de utilidade do design de UI, e adaptar tudo a ela, a qualquer custo, vira um mandamento moral absoluto
Seria ótimo se uma das distribuições assumisse esse papel
“Concordo que paradigmas modernos de design são, em muitos aspectos, amigáveis para usuários iniciantes, mas em algum momento as pessoas deixam de ser iniciantes. Pessoas que passam várias horas por dia no computador e executam tarefas variadas em vários programas também precisam ser consideradas no design. Por isso, minha crítica vem da chamada perspectiva de usuário avançado. Além disso, quanto mais coisas uma interface esconde, menos oportunidades ela dá para o usuário crescer e aprender”
Depois de dizer tudo isso, acho exagero reclamar que é preciso usar um atalho de teclado
Além disso, esse recurso de qualquer forma é algo que exige teclado
A reclamação sobre não haver botão de subir um nível e a crítica à visualização em lista também são pouco convincentes
No screenshot, o ícone de lista era imediatamente reconhecível, e eu até vejo com bons olhos uma janela que não espalha botões de funções duplicadas por toda parte
A afirmação de que “é difícil clicar” também é estranha
A pessoa diz que usa computadores há 35 anos, mas não consegue clicar em um caminho com o mouse; isso é difícil de aceitar
Lê-se como uma reclamação típica de alguém que, depois de se acostumar um pouco com um sistema, passa a se considerar usuário avançado e espera que todo o resto funcione exatamente do mesmo jeito
São as mesmas pessoas que costumam reclamar que, no terminal, não dá para copiar com
Ctrl-C, dizendo que o “atalho padrão” foi quebradoSó porque algo é fácil para você não significa que seja fácil para os outros, e essa é a premissa do trabalho de usabilidade
É difícil acreditar que comunidades técnicas como esta resistam tanto a um ponto tão básico da cognição humana
Na verdade, esse comentário é que é uma reclamação, enquanto o texto original aplica dados reais vindos de décadas de pesquisa
Um texto que escrevi antes: https://news.ycombinator.com/item?id=41303387
Eu nem teria imaginado que o ícone fosse um toggle
Ele nem é renderizado como um toggle, e eu esperaria que houvesse mais de duas opções de visualização
Também é possível colar um caminho
Pode-se usar tecnologias assistivas, como ditado, e também há ambientes, como celulares, em que existem métodos de entrada, mas não há como pressionar
CtrlClaro que UIs de celular devem ser avaliadas por outros critérios
Pior ainda: não há nenhuma consistência entre quais atalhos cada aplicativo de terminal usa
É uma bagunça, e é algo digno de reclamação
Eu só fiquei sabendo alguns anos atrás, depois de ler um texto parecido com o original que criticava a remoção da caixa de texto
Caso contrário, eu jamais saberia que era possível ativar a caixa de texto do caminho por meio de um atalho de teclado
A UI não deve ser apenas fácil de usar; ela também deve ser descobrível
Se até usuários avançados têm dificuldade de encontrar os recursos de que precisam, por que deveríamos achar que o restante da UI é fácil e descobrível para todo mundo?
Para ser sincero, quase não uso a UI e normalmente uso o terminal; só uso o gerenciador de arquivos do Jade quando faço upgrade do firmware do teclado
A caixa de diálogo de salvar foi corrigida?
Quando digito
-s filename, espero que o arquivo atual seja salvo como filenameA extensão pode ou não ser adicionada
O comportamento do gtk-2 era que, quando você começava a digitar filename, ele pesquisava a lista de arquivos/diretórios e, ao pressionar
Enter, selecionava o item destacadoDe qualquer forma, não pretendo instalar o GNOME para verificar
Também não me surpreende que o navegador de arquivos seja tão ruim quanto o texto descreve
O modelo de engenharia de software cadt (cascade of attention deficit teenagers), do jwz, originalmente tentava explicar o comportamento do projeto GNOME
Então está corrigido
Não entendo a obsessão por uma UI “limpa”
Não consigo entender como esconder tudo e trocar por grandes espaços em branco e ícones sem características é “calmo”
Parece estéril e frio, como uma casa vazia ou uma oficina sem uso
Acho bom que existam opções menos complicadas, e não vejo por que todos os ambientes desktop deveriam funcionar do mesmo jeito
Simplesmente funciona, não precisa ser mexida e não atrapalha
O pior no GNOME, incluindo o Files, é o
gtkfilechooserwidget.cdo gtk3 e gtk4Há um bug em que, se você cola um caminho de arquivo na caixa de diálogo
file->open, dá erro e aparece um pop-upOs desenvolvedores do Gtk dizem que o código do filechooser é tão código espaguete que ninguém quer voltar a tornar o modo de localização por entrada de filename o comportamento padrão
Eu concordo
Tentei de forma intermitente durante um ano aplicar patches diretamente no gtk 3.22 e 3.24, mas só consegui corrigir a primeira execução de
File->Opende um processo específico; nas aberturas seguintes o erro voltavaA UI do GNOME e o Gtk pós-2014 não foram escritos pensando em quem usa teclado
Essa é a maior fraqueza da UI
É um dos vários pontos dolorosos do GNOME e um problema que acompanha o GNOME há muito tempo
Mas o GNOME é bastante, talvez principalmente, centrado no teclado
Existe o meme, desde o 3.0, de que “foi feito priorizando toque”, mas provavelmente ninguém que diz isso realmente usou o GNOME em um dispositivo touch
É um pesadelo
Os controles principais do GNOME são feitos por atalhos de teclado ou por gestos amplos de mouse que têm alternativas mais rápidas pelo teclado
Essas reclamações não estão erradas, mas fico curioso para saber quantos usuários de fato tropeçam nessas coisas
Clicar em um ícone que parece uma lista quando você quer a visualização em lista não é um comportamento estranho
Concordo que o comportamento do dropdown é meio estranho
Da mesma forma, hoje já se aceita que muitos apps do GNOME tenham controles na barra de título
Não acho tão incômodo assim que a janela se mova se você não clicar exatamente no controle e começar a arrastar o mouse
Mas o GNOME diz: “nosso software é feito para ser usado por todos. Nós nos importamos profundamente com a experiência do usuário”
Já há uma quantidade enorme de críticas ao GNOME, e eu mesmo já escrevi algumas aqui, então falar mais parece perda de tempo
Os desenvolvedores têm uma visão muito clara do que querem alcançar e não vão mudar de ideia
Os usuários também gostam desse jeito e se sentem confortáveis com ele, então não vão mudar de ideia
Quem não gosta, ou deixou de gostar, também não vai mudar de ideia, porque acha estranho, confuso e limitador
Faz mais de 10 anos que seguem nessa direção e quase não vão mudar
Como o autor disse, o GNOME é um projeto “muito vocal, isto é, dogmático, sobre como as coisas devem ser feitas”
No fim, se você gosta do jeito GNOME, use; se não, vá para outro lugar
Só que isso contradiz um pouco o lema de “ser usado por todos”
Ao implementar suas próprias decorações e desenho de janela, as abas ocupam 95% da área arrastável da barra de título, então muitas vezes você tenta mover a janela e acaba movendo uma aba
Não sei quem vai recuar primeiro nessa situação de design horrorosa, mas quem paga o preço é o usuário
Sinceramente, quem precisa mudar são os navegadores
O GNOME mostrou que é o padrão para a maioria das pessoas e é bastante teimoso