14 pontos por GN⁺ 2025-10-31 | 9 comentários | Compartilhar no WhatsApp
  • A interface de usuário (UI) complexa do software livre funciona como uma barreira de entrada para usuários comuns
  • Até tarefas simples, como conversão de vídeo, acabam sendo abandonadas por pessoas comuns por causa da UI voltada a especialistas de ferramentas como o Handbrake
  • Para resolver isso, o autor criou um frontend simples chamado Magicbrake, com uma interface de botão único, que oferece apenas a função de “converter arquivos de vídeo estranhos em MP4s normais”
  • Ao esconder a complexidade e expor apenas os 20% de funcionalidades que a maioria dos usuários realmente precisa, aumentam-se a produtividade e a satisfação
  • O ecossistema de software livre precisa adotar um design amigável para usuários comuns para ampliar o alcance de uso das ferramentas

A distância entre o software livre e o usuário comum

  • Usuários comuns enfrentam dificuldades com problemas de formato até em tarefas básicas, como converter, enviar e reproduzir vídeos
    • Qualquer formato que não seja reproduzido no QuickTime ou no Facebook é percebido como “estranho”
  • O Handbrake é poderoso, mas sua UI voltada a usuários avançados causa incômodo e confusão em usuários comuns
  • Esse problema é comum em todo o universo do FOSS (Free and Open Source Software) e, como resultado, usuários comuns acabam desistindo ou pedindo ajuda a especialistas

O caso do Magicbrake

  • O Magicbrake esconde os recursos complexos do Handbrake e executa apenas uma única função: “converter vídeos estranhos em MP4s normais”
    • O resultado da conversão é, na maioria dos casos, um arquivo MP4 pequeno que funciona na maior parte dos ambientes
    • A interface tem apenas um botão
  • Essa abordagem é uma solução rápida e simples, adequada para usuários que não precisam de recursos complexos

Objeções à simplificação e respostas

  • Algumas pessoas questionam: “por que deixar o Handbrake menos poderoso?”, “e se eu precisar de outro formato?”, “e os recursos especiais?”
  • A resposta é clara: quem precisa de recursos avançados pode continuar usando o Handbrake como está, e quem não precisa pode usar uma ferramenta simples
  • A ideia é semelhante a cobrir com fita os botões desnecessários de um controle remoto de TV: as funções continuam existindo quando necessárias, mas não atrapalham o uso básico

O valor de uma UI simples

  • Há muitas ferramentas por aí, como servidores de mídia difíceis para pessoas comuns configurarem, editores de áudio que exigem aprendizado até para tarefas básicas e ferramentas de monitoramento de rede que excluem iniciantes
  • Essas ferramentas são excelentes em funcionalidade, mas ficam inacessíveis para usuários comuns por causa de um design que tenta colocar todos os recursos em uma única UI
  • Como 80% dos usuários precisam de apenas 20% das funcionalidades, esconder o restante pode proporcionar uma experiência mais produtiva e satisfatória

Uma proposta aos desenvolvedores

  • Projetar interfaces simples para usuários comuns é algo que pode ser feito em uma única noite e tem valor prático real
  • Em vez de expor toda a complexidade, uma filosofia de design que mostra apenas as funções necessárias melhora a acessibilidade do software livre
  • O autor recomenda aos desenvolvedores criar mais ferramentas simplificadas como essa

9 comentários

 
bumjins 2025-11-01

Pode-se chamar isso de complexidade de UI/UX,
mas acho que o problema é que os softwares feitos hoje em dia, sejam livres ou comerciais, são projetados para só funcionar naquele único caso exato que passa, e não se importam muito com o que acontece com as outras experiências.
Por exemplo, ao editar uma configuração em toml ou yaml, às vezes algo que claramente deveria funcionar simplesmente não funciona. Normalmente não fica bem documentado se isso é um problema de codificação, de indentação, se é um recurso que não pode ser usado quando há uma determinada flag, ou outra coisa do tipo. O usuário acaba testando uma infinidade de casos, um por um, até encontrar a resposta certa com muito esforço.

Na UI isso é ainda mais grave. Como a experiência comum de redefinir senha, que se espalhou como meme, se há 100 campos na tela, não dá para saber sem testar qual é a relação entre eles ou qual é a melhor forma de alterá-los.

Isso também é um problema de UI/UX, mas também de "especialização" oculta. Sem uma espécie de curva de aprendizado em etapas preparada, um problema que uma pessoa com conhecimento especializado consegue resolver imediatamente preenchendo a resposta certa acaba, para um iniciante, funcionando como uma prova ou barreira que o faz passar por inúmeras rejeições.

 
lunamoth 2025-10-31

Em um contexto parecido, parece que GUI é mais confortável do que CLI. Também uso yt-dlp com a GUI yt-dlg. No caso do ffmpeg, costumo deixar anotados os comandos que uso com frequência e ir usando, mas talvez também desse para fazer uma GUI.

 
shakespeares 2025-10-31

Como sempre, é a UI/UX!!

 
euphcat 2025-10-31

Pessoalmente, já pensei bastante em algo parecido, então concordo bastante. Quando eu tentava encontrar no Linux aplicativos como o Paint, o Bloco de Notas ou o Media Player da era WinXP~7, daqueles que “você simplesmente abre rapidinho e usa de qualquer jeito”, eu só dava sorte se, depois de instalar uns 5 ou 6, encontrasse algum de que gostasse.

Eu só precisava tirar uma captura de tela e recortar, mas não dava para usar o Gimp; não lembro o que mais tentei, mas não consegui achar nada entre os apps GTK, então no fim acabei ficando com o Kolourpaint. Para o bloco de notas, tem Gedit, Kate, Mousepad, Leafpad, Xed etc.; e, se quiser algo ainda mais leve que isso, tem que partir para coisas como xedit, nano e vim, que praticamente desistiram de ser amigáveis para o usuário. Só de pensar em players de mídia como mpv, VLC e mplayer já começa a me dar aflição.

 
skageektp 2025-10-31

Esses textos ficam meio estranhos por afirmarem que estão certos sem nem apresentar algo como estatísticas.

 
xguru 2025-10-31

Os usuários só se importam com 20% de um aplicativo
De certa forma, parece estar ligado ao texto acima também.

 
kayws426 2025-10-31

"A maioria dos usuários usa apenas cerca de 20% das funcionalidades de um aplicativo de que precisa, mas esses 20% são diferentes para cada usuário"
Não é esse o ponto principal?

 
ndrgrd 2025-11-01

Sempre que alguém faz qualquer pergunta, aparece a resposta "leia primeiro o man/readme/docs"
na verdade, no UX, o importante é que a pessoa consiga entender como usar só de começar a usar

como não é um trabalho pelo qual estão sendo pagos, isso acaba sendo relevado, mas, do ponto de vista de um usuário não desenvolvedor, é verdade que a experiência de uso não é boa

 
GN⁺ 2025-10-31
Comentários no Hacker News
  • É um bom texto, mas acho que a lógica está errada
    Criar uma interface simples e concisa nunca é algo fácil
    Implementar uma UI voltada a um caso de uso específico não é tão difícil, mas o realmente difícil é definir esse “caso de uso exato” e impedir pedidos do tipo “dá para acrescentar só mais isso”
    Essa simplicidade é desejável, mas é um estado instável

    • O mundo dos desenvolvedores não entende intuitivamente a dificuldade de projetar boas interfaces para quem não é desenvolvedor
      A complexidade do código é visível, mas a complexidade da UI não é
      Botões e campos de entrada parecem simples, mas resolver problemas nessa linguagem é extremamente complexo
      O fracasso é claro, mas o sucesso é ambíguo e varia de usuário para usuário
      Numa boa interface, muita coisa é transmitida de forma “implícita”, e essa é justamente a parte mais difícil
    • Usuários comuns frequentemente fazem pedidos absurdos, como “esse botão pode fazer X?”
      Mesmo que o botão quase não tenha relação com sua função original Y, insistem que ele precisa fazer aquilo
      Pedidos desse tipo, de “muda só um pouquinho”, vão se acumulando, a UI fica cada vez mais complexa e acaba desmoronando
    • A maioria dos contribuidores de código aberto são usuários avançados, então se concentram apenas em saber se o próprio fluxo de trabalho deles funciona bem
      Não querem sacrificar a própria conveniência pela usabilidade dos 80% de usuários comuns
    • Como forma de evitar esse colapso de UI/UX, foi proposta a ideia de “feature freezing”
      Define-se o conjunto de funcionalidades com antecedência e, depois disso, o foco passa a ser correção de bugs e melhorias de eficiência
      Novos recursos só poderiam ser adicionados após uma revisão rigorosa
      Isso é difícil em softwares que mudam rápido, mas acho que funcionaria na maioria das áreas mais estáveis
    • No curto prazo, parece que isso será resolvido com o usuário perguntando a uma IA como o ChatGPT algo como “faça meu vídeo rodar no celular” e recebendo instruções passo a passo
      No longo prazo, o próprio aplicativo pode integrar IA e evoluir para gerar automaticamente a UI que o usuário deseja
  • Acho que esse problema no fim das contas é uma questão de familiaridade
    Minha esposa não é muito acostumada com tecnologia, mas usa Linux
    Quando começou um novo negócio e precisou usar Windows, achou tudo tão desconfortável que quis voltar para o Linux
    Eu também tive uma experiência parecida com Mac vs PC
    Quando fui obrigado a usar Mac, minha produtividade caiu para algo como 10%, e foi bem sofrido
    No fim, as pessoas trabalham melhor no ambiente ao qual estão acostumadas

    • Quando eu estava no ensino fundamental II, o computador da família quebrou e instalei Ubuntu, e minha mãe se adaptou rapidamente
      No fim das contas, era “só um computador”
    • Eu também recebi um Mac da empresa, mas quase não uso
      Felizmente, VPN e os apps de que preciso funcionam todos com Linux + interface web
    • Nas discussões sobre adoção de Linux no desktop, a importância da familiaridade é subestimada
      É preciso uma distribuição estável que ofereça uma UI quase idêntica à de um sistema operacional comercial e que não exija abrir o terminal
      Não basta ser “parecido”; o que importa é o acabamento nos detalhes
  • UIs de código aberto no começo parecem estranhas e complexas
    Como são feitas com foco em desenvolvedores, o princípio de “não surpreender o usuário” não é respeitado para o usuário comum
    Mas, usando com consistência, a pessoa acaba se acostumando com a nova filosofia e consegue usar bem
    Eu mesmo uso bem Firefox, LibreOffice, Avidemux e Virt-manager

    • Hoje em dia sinto que quase não há diferença entre Firefox e Chrome
      O problema é a falta de designers
      Em FOSS, quem participa em geral são desenvolvedores com algum tempo livre, mas há relativamente poucos artistas ou designers
      Por isso, muitas vezes só se oferece uma UI de nível básico
  • Os problemas de UX do editor de áudio gratuito Audacity já são reconhecidos pelos designers
    Foi publicado um vídeo de redesign de UX tentando resolver os problemas de “modos” e “Audacity says no”
    Deve melhorar no futuro; ainda falta boa UX no código aberto, mas isso está mudando

    • UX é a maior dívida
      No começo, o app é criado para uso próprio, mas depois as pessoas dizem “a funcionalidade é boa, mas a UX é ruim”
      Por outro lado, quando a UX melhora, dizem “faltam recursos”
      No fim, tentando agradar todo mundo, cai-se num inferno interminável de redesign
      Em muitos casos o projeto desmorona ao tentar criar coisas como um motor de temas
    • O problema do novo Audacity não é a nova versão em si, mas o fato de ela substituir a versão existente
      Se tivesse sido lançada como algo novo, com outro nome, ninguém teria reclamado
  • Acho que a solução para esse problema está na padronização em nível de SO
    O sistema operacional deve oferecer UI e fluxo de trabalho de forma consistente
    Por exemplo, em vez de “Handbrake”, haveria um app padrão chamado “Video Converter”,
    capaz de entender comandos como “converta para tocar no Facebook” e aplicar automaticamente as configurações
    A marca dos apps deveria ser minimizada, e o usuário deveria ter controle total sobre tema e fontes
    Também seria necessária uma linguagem shell padronizada conectada às funções da GUI

  • No fim, as pessoas querem mesmo é funcionalidade
    Mesmo com uma UI complexa, se der para fazer o que querem depois de aprender, elas aceitam
    Softwares com apenas opções simples têm mercado pequeno
    Usuários que não entendem formatos de vídeo acabam resolvendo pesquisando por “convert x to y” em algum site
    Se alguém usa uma ferramenta profissional desse tipo, já entrou no território de usuário especializado

    • Mas isso não significa que “software complexo” seja necessariamente indispensável
      Também dá para ter uma UI simples, do tipo “solte o arquivo aqui e clique em Fix It”
      Acho que esse é justamente o ponto principal do texto original
  • Há vários motivos para software de código aberto ser complexo

    1. desenvolvedores fazem para as próprias necessidades
    2. o custo de adicionar opções é baixo
    3. não fazem pesquisa com usuários
    4. quem consegue instalar isso já é, por definição, um usuário avançado
    • Por exemplo, Sonobus recebe boas avaliações até de usuários comuns
      Mas a maioria dos FOSS é estruturada de forma que exige letramento técnico
      Aprender software complexo pode, na verdade, ser mais eficiente no longo prazo
    • Manter uma interface minimalista exige muito tempo e energia
      Para desenvolvedores de código aberto, é difícil colocar isso como prioridade dentro do tempo limitado que têm
  • Há a piada de que, se Handbrake já parece difícil, então melhor nem mostrar o ffmpeg
    Quando usei Handbrake pela primeira vez, também achei muito mais fácil do que ffmpeg

    • Na maioria dos casos, com ffmpeg basta procurar no Google “como fazer X com ffmpeg” e logo aparece um comando para copiar e colar
      Já ferramentas com GUI exigem assistir vídeos para aprender
    • Se você só quer uma conversão simples, ffmpeg é a UI mais simples
      ffmpeg -i input.avi output.mp4 e pronto
    • Para quem está acostumado com linha de comando, ffmpeg é mais simples que Handbrake
      Handbrake mostra todas as opções, enquanto no ffmpeg você só digita o necessário
      Depois que pega o jeito, ele oferece um controle muito preciso
      Essa simplicidade de “basta informar entrada e saída” acaba sendo justamente o atrativo
    • Eu ainda uso bastante busca com LLM quando vou procurar comandos de conversão no ffmpeg
      Não é perfeito, mas sinto que costuma ser melhor do que eu
    • Acho até que Handbrake é simples justamente por causa do fluxo de trabalho baseado em presets
      Por isso, esse exemplo do texto original me parece um pouco estranho
  • Pessoas como eu preferem interfaces complexas
    Quero que presumam que sou inteligente
    Quanto mais frequente é o uso da ferramenta, mais vale a pena que ela permita trabalhar rápido, mesmo sendo complexa

  • O problema é que cada pessoa quer um 20% de funcionalidades diferente
    Boa UI/UX exige um ciclo de feedback muito próximo entre testadores, designers, desenvolvedores e usuários
    FOSS não tem recursos suficientes para isso

    • Na prática, 80% dos usuários comuns querem os mesmos 20% de funcionalidades
      Mas o usuário médio de FOSS é um usuário avançado do 1% do topo, então não entende isso
      Por isso, quando se tenta mudar o foco para usuários comuns, a comunidade reage mal
    • Muitas vezes FOSS nem é feito para “clientes” em primeiro lugar
      O desenvolvedor cria para suprir a própria necessidade, então satisfação do usuário pode nem ser o objetivo
      Isso não é fracasso; é apenas um objetivo diferente
    • No caso de algo como Handbrake, a maioria das pessoas só quer reduzir o tamanho do vídeo
      Só uma minoria usa os recursos avançados
      Por isso, separar em UI básica + modo avançado é o caminho mais realista
    • O ciclo de feedback em FOSS é auto-reforçador
      Como só testam usuários já acostumados com aquela UI, aparecem muitas opiniões do tipo “não mexa nisso”
      Já grandes empresas podem fazer testes pagos com novos usuários
      Por isso, conseguem melhorar UX mais rápido
    • 99% da comunidade FOSS é formada por desenvolvedores
      Quando se pede contribuição a especialistas em UI/UX, quase sempre eles não são compreendidos