web design

Por que fugir de “soluções próprias” em web design?

No começo da década de 1980, havia dezenas de microcomputadores a disputar mercado. Apple, IBM-PC, MSX, ZX Spectrum, Commodore 64, CP-400, Sinclair… a lista parecia infindável. Cada um deles possuía processador e arquitetura próprios, uma linguagem particular e softwares que eram exclusivos para uso em suas respetivas plataformas. Hoje, trinta e poucos anos depois, apenas dois deles permanecem.

Por que todos os outros se foram?

A questão é que, para o usuário, o fato de utilizar máquinas que não possam “dialogar” com sistemas de seu vizinho, amigos ou colegas, torna essas máquinas completamente inúteis. No mundo da internet, a capacidade de intercomunicação dos computadores tornou-se ainda mais vital. Documentos e ficheiros são compartilhados por todo lado e até mesmo atualizados por mais de uma pessoa, e portanto precisam seguir um mesmo padrão.

Os padrões, nesse caso, seguiram adiante com as plataformas que possuíam melhor suporte e manutenção, mais segurança, porte e escalabilidade. Em outras palavras: aquelas que eram mais bem feitas. O mesmo ocorreu com softwares nos anos 1990, incluindo navegadores de internet. O benchmark é estabelecido por uma série de razões – e aqueles que permanecem fora dele correm o risco de ser esquecidos e ultrapassados.

Que isso tem a ver com web design?

Toda essa longa história para chegar ao web design. Na era atual, centenas de plataformas para organização de conteúdo e criação de websites foram criadas e difundidas. Algumas delas sequer chegaram a ter algum destaque, outras tiveram seu auge e logo em seguida declínio. A questão é que, mesmo no momento atual, no qual benchmarks já foram estabelecidos, ainda há aqueles que operam na banda obsoleta do web design.

Como clientes, é difícil perceber quando nos deparamos com algo completamente ultrapassado. Contudo, ter em mente aquilo que está realmente em alta e uso na internet dos dias de hoje pode ser útil. Em primeiro lugar, há que se diferenciar conteúdo estático do dinámico. Para quem não sabe a diferença, ela é, na verdade, bastante simples:

  • Sites de conteúdo estático são aqueles criados em HTML para visualização, cujo conteúdo inserido não varia ou não pode ser atualizado e inserido por qualquer espécie de sistema. Nessas páginas estáticas, alterações no conteúdo têm de ser feitas a partir dos próprios ficheiros HTML.
  • Quando o conteúdo é dinámico, o HTML é apenas uma espécie de “modelo”. Esse esqueleto formado pelo HTML recebe um conteúdo enviado por uma aplicação que roda em um servidor. Esse tipo de sistema geralmente opera em duas frentes: a primeira delas, o frontend, ou seja, a própria visualização para o usuário. O segundo é o backend – uma plataforma a partir da qual o proprietário do site insere e altera o conteúdo, que é dinamicamente inserido nos modelos HTML.

Em termos de frontend, ambos os sites possuem características semelhantes: uma estrutura construída em HTML, uma formatação feita a partir de ficheiros ou instruções CSS e efeitos e interações produzidos a partir de rotinas em Javascript. Quando têm-se um conteúdo dinámico, no entanto, esses modelos de frontend são “recheados” com conteúdo que é enviado a partir de um servidor, geralmente com o uso de sistemas programados em PHP e outras linguagens, os chamados CMS (Content Management Systems).

Como identificar “soluções próprias” em frontend?

Montar modelos HTML ou sites em HTML para exibição estática exige, nos dias de hoje, toneladas de estilos em CSS e rotinas Javascript para eventos como a abertura de pop-ups, processamento de formulários, animações e outros. “Soluções próprias”, nesse caso, são projetos construídos geralmente do zero, sem seguir qualquer padrão, boas práticas ou sistemas mais universais. O grande problema, além do grau de confiabilidade dos web designers que operam assim, é a falta de “diálogo” com outros sistemas.

Quando projetamos um website que utiliza modelos, frameworks e estilos mais universais, isso permite que outros designers possam operar igualmente o website, que atualizações possam ser feitas de maneira simples e que melhores práticas seguidas por web designers de todo o mundo estejam presentes em seu site. O CSS é parte importante desse processo de padronização, o que geralmente implica no uso de frameworks com amplo suporte e adesão no mercado:

  • Twitter Bootstrap
  • ZURB Foundation
  • Bulma
  • Semantic UI

Fora a grande adesão, todos esses frameworks possuem uma documentação. Isso quer dizer que qualquer outro profissional que venha a lidar com o website (inclusive seu dono, caso pretenda meter-se em programação e design) será capaz de perceber o que ali foi feito. Quando a “solução própria” aparece, quem quer que venha a mexer com o site no futuro estará em maus bocados.

Finalmente, esses sistemas são modernos. Todos estão em versões adiantadas, e evoluíram conforme a própria web evoluiu, adicionando com o tempo funcionalidades técnicas para uso e aplicação em mobile, compatibilização com navegadores, inserção de novas tecnologias e outros.

Soluções próprias muitas vezes não utilizam tais modelos. Isso não implica necessariamente num trabalho ruim, porém cria certa dificuldade para que novos ou outros profissionais lidem com o conteúdo e layout no futuro. Além disso, esses frameworks são constantemente atualizados e aprimorados por uma comunidade de dezenas de milhares de profissionais – o mesmo não se pode dizer de layouts criados a partir de modelos próprios, sem padronização ou avanço conforme melhores práticas do web design.

Como identificar “soluções próprias” em backend?

Para simplificar: o dito “backend” é basicamente a parte na qual os proprietários do site utilizam seu login para efetuar mudanças, inserir conteúdo, instalar aplicações e funcionalidades e outros. Todos os sistemas de CMS ou e-commerce possuem uma plataforma de backend. WordPress, Drupal, Magento, Moodle – todos possuem uma área na qual o dono de um website é capaz de gerenciar seus recursos principais.

cms

Sistemas de gestão de sites desenvolvidos como “soluções próprias” geralmente parecem algo improvisado e não atentam para necessidades do usuário e de UI.

Essas áreas de administração são pensadas no sentido de facilitar a operação do website por pessoas que não são especialistas ou informáticos. Por anos, versões foram sendo avaliadas, aprimoradas, criticadas, de forma a alterar e evoluir ferramentas que hoje permitem que praticamente qualquer um efetue mudanças quase que totais em seu website. No time das soluções próprias, contudo, temos muitas vezes plataformas de inserção de conteúdo improvisadas, não testadas, que utilizam modelos não amigáveis e são destituídas de qualquer óptica do usuário.

Muitos argumentam a respeito da “segurança”, como forma de justificar a criação de plataformas próprias improvisadas em lugar de sistemas como o do WordPress. O engano não poderia ser maior: todo código possui falhas e brechas que podem ser exploradas, mas apenas aqueles em constante atualização podem ser considerados seguros. É simplesmente difícil acreditar que uma plataforma mantida por milhares de programadores e com mais de uma década de sucesso seja “menos segura” do que um website construído em meses por dois ou três programadores de vinte e tantos anos.

cms

Áreas de administração como a do WordPress são pensadas sob a óptica do usuário, mas ainda assim permitem interação para desenvolvedores e programadores.

As soluções próprias são facilmente identificáveis, mesmo na fase de proposta por parte dos criadores e programadores. Para identificá-las (e delas fugir), o empresário pode atentar nos seguintes tópicos:

  • Necessidade de “contactar” com os desenvolvedores quando novos conteúdos precisam de ser incluídos
  • Cobranças de taxas de “manutenção” que não incluem qualquer serviço (o que é irónico, pois todos os CMS de sucesso no mercado são open source, gratuitos e possuem manutenção frequente… sem cobrar um cêntimo para tal)
  • Plataformas de login e acesso sem qualidade visual e amigabilidade para o operador

Há ainda o argumento do preço. Alguns desenvolvedores afirmam a clientes que criar sites em sistemas como o WordPress é algo “caro”. Bem, quando compra-se plugins e temas para qualquer ajuste ou acerto no site, realmente o WordPress torna-se dispendioso. No entanto, se são eles programadores, cabe a pergunta: por que estão a instalar módulos prontos para tudo quando os podiam desenvolver?

O caminho da solução própria aponta, em geral, para sites sem possibilidade futura de evolução, sem liberdade de operação para as empresas e com suporte zero em termos de segurança. Em situações como a entrada em vigor das regras do GDPR europeu, eles podem se tornar inclusive uma bomba-relógio.