Software livre e os designers
Enviado por Paulo Cesar (puelocesarΘgmail·com):
“Escrevi este texto na disciplina de Metodologia da Pesquisa em Design de Interação, que fala sobre o problema da participação de designers no SL, algumas causas, e algumas dicas de como superar este problema” [referência: faberludens.com.br]
• Publicado por Augusto Campos em
2011-07-15
@brlinuxblog
Feed RSS
Sem querer trollar, achei o texto uma bobagem. A parte da suposta meritocracia, então, nem se fala.
“Vai lá e codifique você mesmo” significa que o desenvolvedor não vai fazer o que pediu (pois não concorda, não quer ou qualquer outro motivo) e você tem a possibilidade de fazer você mesmo. Se não sabe, pode aprender. Se não quer aprender, pode pagar pra alguém fazer.
Não adianta apontar os erros? Que tal o autor nos mostrar os registros de bug tracking que ele fez e recebeu essas respostas? Ao menos eu já registrei vários bugs e sempre foram reconhecidos (quando fizeram sentido, óbvio) e fui até agradecido. Ninguém me mandou corrigir.
E o que acontece se você apontar o “erro” de um software proprietário? Eles vão lá e deixam do seu jeito? Não é mais provável que seja ignorado ou seja uma resposta padrão?
Sinceramente, pra mim é muito mimimi. Toda hora aparece alguém querendo escrever como o mundo do software livre seria melhor se fosse desse ou daquele jeito.
Quem ler o texto e depois ler o comentário do usuário Franco vai entender o que o autor quiz dizer.
Pra mim ficou evidente o posicionamento de alguns membros da comunidade diante de criticas, que nesse caso considerei positivas.
@Junior
Então nós devíamos ver quais foram os relatos de erro que o autor fez para avaliar melhor. Veríamos se realmente ele apontou erros e recebeu esse tipo de resposta. Me arrisco a dizer que ele não tem um relato sequer.
Na minha experiência, todos os bugs que relatei foram aceitos. Desde erros de tradução ou português, até erros de verdade. E quase sempre com um “obrigado” no fim.
Outra coisa: ficou evidente o posicionamento de ALGUNS membros ao ler meu comentário? É feio generalizar, amigo.
Qualquer software pode ser bom como for, bem codificado, endentado, documentado, mas será um lixo se a interface não for bem desenhada.
Software livre é participativo. A comunidade “dita” os rumos. Lembro que anos atrás, Mark Shuttleworth solicitou printscreens dos desktops dos usuários. O que vemos hoje, as cores que vemos hoje, podem muito bem refletir a forma como os usuários apresentaram seus Desktops ao Mark.
A Apple tem um Desktop e sistema “blink blink” porque ela fechou todo o seu código, para para programadores programarem e para designers desenharem. Quando você paga por um Apple, o salario dos dois está incluso. Quando você baixa um SL, quem você tá pagando?
Por ser colaborativo, ele depende muito da ação da comunidade. Você é designer e pode criar algo que, se não original, ao menos seja diferente do atual e não copia tudo do outro? Manda ver. Não sabe mas conhece quem sabe? Pede um help, uma colaboração…
A Canonical tem seus designers contratados para trabalharem no Ubuntu. O Ubuntu é hoje um sistema completamente diferente do que era no 7.10, por exemplo.
Não é ser ignorante, mas muito do trabalho do SL depende de pessoas que tem de sustentar suas casas, pagar suas contas e para isso tem outro emprego. Ajuda no SL por amor à causa (e uma certa busca de reconhecimento). Agora pergunta a um designer de interfaces, se ele pode dispor de uma hora por dia de trabalho voluntário em um SL (o GIMP precisa muito, muito mesmo)…ah sim, e como design é arte, corre o risco de não agradar, já que arte é “subjetiva”…
No fim das contas é isso. Se o SL é livre, mas é cobrado, tenha a quase certeza de que ele terá um design muito melhor que os não-pagos.
Esse pessoal, porque usa Linux e se acha geek, pensa que tem o direito de sair cobrando e reclamando de todo mundo.
Essas pessoas que reclamam e blábláblá, quantos softwares já criaram? São desenvolvedores de quais projetos?
Ponto.
Vá estudar e faça algo de útil, blogueiros profissionais.
Não concordo com o texto. Vários projetos possuem noções diferentes de design de interfaces (tanto o KDE, quanto o GNOME e o Unity possuem regras de design para suas aplicações), e é mais que natural as pessoas concordarem com uma interface – ou detestarem todas =D
E, visto que há diferentes noções de “bom design” circulando no meio da comunidade SL (e diferentes formas de cada subgrupo chegar à sua noção), fica difícil aceitar que os desenvolvedores de SL não discutem (ou se preocupam) com o design das aplicações.
Existe um abismo entre o Software Livre mantido pela comunidade e o Software Livre mantido por Empresas.
Vejamos os exemplos Gtk x QT.
Eu, por motivos puramente ideológicos, uso Gtk mas a biblioteca QT está anos luz na frente tanto tecnicamente falando quanto em termos de documentação.
Recentemente submeti um bug que encontrei pra equipe de desenvolvimento do Gtk e, após 40 dias, sequer recebi uma posição. Consultando o Bugtrack verifiquei que o erro nem foi analisado e sequer recebeu algum nível de criticidade.
Logo… fica difícil pra algumas empresas utilizarem Gtk em projetos maiores e, consequentemente, contribuirem com a equipe de desenvolvimento da Lib,framework,etc., seja tecnica ou financeiramente.
Falando de desing…até hoje me pergunto por que o unity existe (sentimento old school mode=on).
Quanto ao pessoal carancudo que manda você codar o seu próprio, hehe, aceite (vai ser melhor pra vc, vai aprender um bocado).
Pra finalizar, talvez hoje em dia se fale tanto de desing por causa da maldita maçã e nada mais.
Disclaimer: Eu não sou um blogueiro “profissional”. Eu sequer tenho um blog de verdade. Isso foi um trabalho de pós graduação baseado nas minhas experiências de contribuições de design na comunidade de software livre.
Eu já colaborei com vários softwares durante o desenvolvimento do KDE, mas a única que foi aceita for uma pequena sugestão de layout no visualizador de erros do KDevelop, e para tanto, eu tive que participar durante horas e horas em uma discussão bem chata com um pessoal que não tinha a menor noção de espaçamento, alinhamento ou qualquer conceito básico de design. Foi bem desgastante mas foi bacana o aprendizado.
Com relação à bugs, se você cadastra um defeito de código, é óbvio que ele vai ser corrigido, porque dificilmente o programador vai discordar de você (a não ser que seja alguém do Google no bug tracking do Android, eles são bem arrogantes).
Agora quando se trata de uma melhoria conceitual, dificilmente será aceita, afinal, “quem é esse mané querendo colocar o dedo na minha criação”.
Por último, tem a questão de que o modelo mental do desenvolvedor é diferente do modelo mental de uma pessoa normal*, então em muitos casos, uma coisa que é óbvia para ele, não vai fazer o menor sentido para a maioria das pessoas. Isso é uma coisa normal, o problema é que muitos programadores não entendem este conceito, e vão bater o pé até cansar para que seu modelo mental seja considerado como “o correto”.
Bom, mas é isso, eu não quero criar nenhum flame war nem ofender ninguém, só queria tentar gerar uma discussão a respeito do tema, e estou aberto a críticas, opiniões contrárias e tudo mais. Só peço para que quando lerem algo que não gostem, ao invés de tentar sujar a imagem do autor, leiam com a mente aberta e façam críticas coerentes, e não coisas do tipo “vai trabalhar vagabundo”.
*eu também sou programador, então eu posso falar isso
correção: durante o desenvolvimento do KDE4
Tem mais uma coisa que eu esqueci de falar, para quem quiser conhecer mais sobre o assunto Design de Interação, lá no instituto tem uma série de artigos sobre metodologias, métodos e técnicas que pode ser bem útil para alguém que queira desenvolver alguma coisa nova:
http://www.faberludens.com.br/pt-br/node/31
PS: para quem quiser criticar, este link também é útil, porque pelo menos você poderá criticar com um embasamento teórico maior :)
kirotawa: Sim, eu já fiz isso, insatisfeito com os browsers open source no Maemo eu criei o meu próprio: http://maemo.org/downloads/product/OS2008/macuco
https://github.com/puelocesar/Macuco
Foi uma experiência bacana, pois foi muito bem aceito, e quando eu abandonei a plataforma, um engenheiro chinês continuou o projeto. Aliás, sujeito muito gente boa.
Com relação ao desiGN, eu posso lhe dizer que é sim uma disciplina importante e que está bem longe de ser uma coisa “só da maçã”. O design de interação, que é uma das disciplinas do design, possui diversas técnicas bem interessantes para que você entenda melhor seus usuários e desenvolva softwares mais interessantes e relevantes. Segue abaixo um texto de um colega sobre o assunto, que é uma boa introdução:
http://blog.harlley.net/design-de-interacao-programadores-e-empreende
É complicado explicar design pra quem prefere usar linha de comando. Deve ser por isso que sempre dizem pra separar o código da parte gráfica.
Não entrando em detalhes um problema GRAVE da INTERFACE é FALTA DE CONSISTÊNCIA. O sistema e a interface devem DITAR certas regras de FORMA UNIFORME, COERENTE, o usuário fazendo ajustes mas mantendo CONSISTÊNCIA.
Exemplo é selecionar com o mouse e colar com clique na roda, que deveria ser SEMPRE e não ficar à mercê dos aplicativos suportar ou não, quebrando a consistência.
Outra coisa HORROROSA é imitar as torquices de certo sistema “operacional” com atalhos nos menus com UM caracter sublinhado, ficaria bem mais estético em bold ou bold e largo, ou mesmo cor distinta (usuário poderia escolher até). UM caracter apenas sublinhado fica muito esquisito, no mal sentido – coisa típica daquele “sistema”.
Felizmente uma coisa contornável é o duplo-clique na barra de títulos, esperar-se-ia enrolar (recurso inexistente naquela tranqueira “W”) mas maximiza / anterior, sendo que já há o botão p/ tal. Aí tem que entrar nos ajustes e colocar tão interessante “extra” de enrolar. Aliás, essa de enrolar é bem antiga no MacOS.
FALHAS GRAVÍSSIMAS! Há janelas de operações em ajustes e outras que “estravasam” a tela de forma até dificultar operação! E o GtkTerm abre “estourado” em 800×600, nem dá p/ reduzir! Isso ao menos ocorre no Gnome 2.28.1 no Ubuntu 9.10.
Adorei essa discussão. Foi a primeira vez que vi no br-Linux discutir o assunto interface sem o povo anarquizar ou ficar fazendo comparações. Tem ser assim: expor os nossos defeitos para corrigir.
@paulocesar, acho que a reação ao teu artigo só mostra a pertinência dele, muito bom, é necessário mesmo insistir nisso. A lógica do “de desenvolvedor para desenvolvedor” não serve em todo canto.
@mfFr0g as vezes quem idolatra o terminal produz código ilégivel sem realce de cores e macarronicamente endentado.
@erico, sim, mas isso não é exclusivo para quem programa aplicações para linha de comando. Na verdade, qual a relação entre qualidade de código e paradigma de interface? Eu posso escrever uma aplicação com código limpo usando Qt4 para linha-de-comando ou fazer um código macarrão numa visualmente aplicação bonita. Se vc quer uma aplicão simples, que recebe uma entrada, processa rapidamente e emite uma saída na tela, em poucas vezes existe a necessidade de um código mais complexo, mas há várias aplicações não-visuais bastante complexas que exigem uma arquitetura melhor (servidores de vários tipos, web, sgbd, etc.)
Concordo com as opiniões acima sobre uniformidade na interface. Tanto em tema quanto em coisas específicas quanto posicionamento dos componentes, espaço entre eles (sim, poucos pixels fazem diferença), etc. Infelizmente no Linux não creio que um dia veremos uma uniformidade geral. É impossível no modelo de desenvolvimento da maioria das distribuições. Mas dá pra seguir algumas coisas em comum. O pessoal do Freedesktop já cuida da interoperabilidade “por baixo dos panos” entre os diferentes desktops. Creio que seja necessário tbm a criação de protocolos que permitam uma melhor interação visual entre as toolkits (atualmente aplicações em gtk conseguem usar o tema e janelas de diálogo (abrir/salvar/imprimir) do qt, e vice-versa), mas o usuário com uma visão mais apurada vai ver que ainda dá pra confundir.
O próprio Windows, ao contrário do que muitos pensam, não mantém uma uniformidade na interface. Eu consigo identificar ao menos quatro diferentes visuais: a mais nova, baseada no ribbon (que é bem antiga e não foi inventada pela MS), a de aplicações como gerenciador de hardware e demais ferramentas administrativas, aquele visual bizarro de aplicações delphi mais antigas, além das de aplicações em .net, que são as mais bonitas, IMO.
Acho que a único que mantém mesmo um padrão é a Apple.
@MrFr0g, separar a visão das regras de negócio também é bom pela razão que citou, mas não só isso. Quanto mais elegante e robusta, mais fácil é manter o desenvolvimento do código. E é um saco entender o código de uma aplicação onde o visual e a lógica de negócio estão numa só unidade (um arquivo, uma classe ou um objeto).
Vários aspectos relativos à interfaces são sim relativos (se fossem absolutos, não mudariam tanto com o tempo, como têm mudado nas últimas décadas), mas vários deles tbm possuem certa dose de objetivismo e formalismo (afinal são baseados em como o ser humano enxerga o mundo como manipula as ferramentas que cria e os outros artefatos na natureza. No caso, isso não mudou muito nos últimos 50 mil anos ou mais (ou 6 mil, caso você acredite no criacionismo)).
dica: é possível dizer que fontes vermelhas em fundo cinza é bom em alguma ocasião?
Flávio,
Estou curioso a respeito de quais motivos ideológicos você tem para usar Gtk em vez de Qt.
Obs.: QT é sigla para QuickTime. O correto é chamar o toolkit de Qt.
Texto incoerente com a realidade.
De qual comunidade você está falando?
Ótimo texto
Da minha parte, já cansei de reportar bugs em diversos softwares, 90% deles são ignorados (a menos nas áreas mais sérias como kernel, mas ai, tenha certeza que é um bug mesmo)
É triste ver que a maioria dos desenvolvedores de SL ignorem a parte de iteração com o usuário, não estou falando nem de ser bonitinho, mas pensar no processo de uso do sw (e bom, muitas vezes pecam na parte técnica também). Sim, dá trabalho
Realmente ocorre isso de bug reports serem ignorados, principalmente em projetos grandes. Mas não culpe os desenvolvedores, eles recebem muita porcaria nos trackers e é difícil triar o que presta. Eu já cheguei a reportar problema de funcionalidade em um software e anexar junto um patch pronto para corrigir e mesmo assim o bugreport foi ignorado. A questão aqui é você saber lidar com pessoas. Se você não sabe socializar e interagir com os desenvolvedores, fica difícil você contribuir dependendo do tamanho e da organização do projeto.
Esqueci de acrescentar que isso ocorre em qualquer projeto, seja de software ou qualquer coisa, seja livre ou proprietário. Mesmo programadores contratados por empresas que desenvolvem software proprietário podem ter dificuldade com isso. Esse é um dos maiores problemas do RH, arrumar gente que seja bom desenvolvedor e que ainda saiba se socializar, argumentar e expor suas ideias para os outros da empresa de forma efetiva.
Nada a ver. A linha de comando é um tipo de interface, específica para reuso e entrada rápida de detalhes. Existem guias de interfaces para linha de comando também (por exemplo, de separação de argumentos e tolerância a erros), assim como existem para aplicações curses (em modo texto com posicionamento e caracteres semigráficos) e gráficas de diferentes ambientes de desktop.
Existem diferentes designs para diferentes ambientes e diferentes públicos. Depende muito do objetivo do software. Para ferramentas profissionais (digamos, um AutoCAD da vida) a facilidade não deixa de ser importante, mas em certas ocasiões a eficiência (fazer uma tarefa mais rapidamente) toma precedência. ISSO é design, é saber se levar pelos prós e contras em cada ocasião e não se deixar levar apenas pelos achismos e intuições superficiais.
Um software como o vi ou emacs prima mais pela eficiência (fazer uma tarefa rapidamente) do que pela facilidade de aprender. Por isso são demoradas de se dominar, mas quem domina faz as tarefas muito mais rapidamente do que quem usa as ferramentas “fáceis” equivalentes.
Muito bom Patola, você pegou o espírito da coisa. Design é função, não estética. E de fato, usabilidade não é tudo, em muitos casos, sacrifica-se a usabilidade em prol de uma experiência divertida ou desafiadora.
Outro ponto em relação a esse assunto que você citou sobre softwares profissionais, como CAD, é que as vezes os profissionais NÃO querem que o software seja nem bonito nem fácil, pelo sentimento de poder que isso traz, de saber usar um software que poucas pessoas sabem. Tem até uma pesquisa sobre isso com aqueles operadores de bolsa de valores, porém eu não achei o link..
Também concordo contigo em relação à linha de comando, mesmo dentro da área de HCI essas interfaces são reconhecidas pela sua rapidez e eficiência. Um exemplo disso é o Aza Raskin, que tenta trazer o poder da linha de comando para todo mundo: http://www.azarask.in/blog/post/ubiquity-in-depth
Agora, já em relação ao emacs, programadores de verdade usam VI: http://xkcd.com/378
Olá! Vou retomar alguns pontos da conversa. Gostaria muito que buscássemos soluções para aproximar design e SL :)
O assunto que o Paulo tocou com seu artigo é extremamente importante. Eu apenas não diria que o SL não “tem design”. Tem design/projeto no SL. A diferença é como este design foi projetado: usuários fora da comunidade foram consultados? Como? Que metodologia? Afinal, inovações desenvolvidas se dão por capacidade técnica (capacidade de produzir) ou para resolver necessidades de uso das pessoas? Entre outras questões.
Gostaria muito de saber, aqui da comunidade, como seria uma abordagem de design que conseguisse se aproximar do SL, de forma consistente. Estamos tentando fazer isso com o Design Livre . Buscar um modo de levar o olhar de design para o SL, mas sem necessariamente seguir os modelos fechados comuns da maioria das empresas. Esse é um estágio pelo qual o SL já passou, mas onde o design ainda está engatinhando. No Design Livre estamos buscando alguns caminhos, inspirados no Software Livre: disponibilizar tudo de modo aberto, com licenças de uso, tanto os resultados como os métodos.
Existem muitas pessoas que não programam mas querem se aproximar de comunidades de SL. Só participa quem programa? Será que não existem pessoas conhecimentos diferentes dos da programação, que podem estar juntos? Um exemplo: foi muito importante para o SL a proximidade com advogados e pessoas com conhecimento em direito, para defender o SL. Estudei um pouco disso neste artigo: “Regulação da participação em comunidades de software livre: abordagem do caso Debian-RS” http://www.gonzatto.com/blog/regulacao-da-participacao-software-livre/
Design vai muito além da maçã e não se trata de “firulas” de interface, mas de detalhes determinantes para a experiência de quem usa. Como é a interação, a usabilidade, a arquitetura da informação, a acessibilidade? Esses “detalhes” podem ser difíceis, em certos momentos, de serem considerados importantes, prioridades de desenvolvimento. Não é – nunca! – uma questão de “colocar design” a força. Mas que tipo de metodologia poderíamos desenvolver para que esta relação entre design e desenvolvimento aconteça de forma horizontal, sem que “um mande no outro” e se preocupar mais com objetivo real, que é melhorar e difundir o Software Livre?
Falar de Bugs é diferente de inconsistências de interface, por exemplo. Acredito que quando um usuário não encontra uma informação em um sistema, ou clica em algo achando que é outra coisa, não se trata de um bug, certo? É um problema que aparece no uso da interface, não apenas de produção da interface (afinal, a informação está lá, em algum lugar). O design busca resolver este tipo de questão.
As vezes o design cai no senso comum de parecer só “arte” ou ser algo “subjetivo”. Comparo isso a alguém dizer que software é tudo igual, seja proprietário, pirata ou SL. Quem está envolvido sabe que a diferença é enorme. No http://www.corais.org temos discutido isso. Como tornar o design livre? Não basta apenas um documento comentado, é preciso mostrar outras coisas para que seja útil para outras pessoas.
Carlos:
Parabéns! Mesmo eu escrevendo “QT” ao invés de “toolkit de Qt”, você entendeu, deve ser um “super dotado”.
Sobre os motivos ideológicos, não vou entrar nesse mérito pois alguns assuntos não se discutem (religião, distribuição preferida,etc.) e não foi essa a questão que levantei.