Tableless - Desenvolvimento inteligente com Padrões Web

23/01/2011
Artigos

Boas práticas na estruturação de interfaces.

O planejamento estrutural de seu código html é também de grande importância para organização de tags e propriedades css, para o trabalho em equipe e para uma manutenção facilitada.

Por


Ao iniciar um novo projeto, precisamos estabelecer um planejamento de tempo de trabalho X modelo de trabalho. Em geral, não há uma regra estabelecida, pois muitos desenvolvedores Front-End acabam por utilizar suas próprias lógicas de estruturação de códigos levando em consideração qualidade em menor tempo.
Conforme vamos adquirido experiência na área, acabamos assimilando e adotando os métodos utilizados na empresa ou agência em que trabalhamos somados à troca de experiência com os outros profissionais. Ainda assim, existem boas práticas, percebidas por profissionais que já estão no mercado há algum tempo, que podem colaborar para que qualidade e velocidade sejam pontos primordiais no desenvolvimento de um website.

Identificando os 3 principais elementos de uma interface

O primeiro passo é identificar os 3 principais elementos do projeto – topo, conteúdo e rodapé. Esses elementos são comuns à maioria das estruturas que temos na web, trazem as principais informações do website e tendem a repetir-se em todas as páginas internas com as mesmas características visuais estabelecidas na “home”.
Ao identificá-los – ainda no arquivos de layout – é importante já observar propriedades básicas desses elementos como: altura, largura e tipo de propriedade que será utilizada para o background desta interface, levando em consideração principalmente a versatilidade deste projeto à diferentes resolução de tela.
Identificadas essas informações, inicie a estruturação da interface pelo código html criando estes 3 elementos:

HTML 4 HTML5
<body>
<div id=”header”>conteúdo topo</div>
<div id=”content”>conteúdo corpo</div>
<div id=”footer”>conteúdo rodapé</div>
</body>
<body>
<header>conteúdo topo</header>
<div id=”content”>conteúdo corpo</div>
<footer>conteúdo rodapé<footer>
</body>

Folhas de estilo externas

O uso de folhas de estilos externas para declaração de propriedades css é uma das práticas que incansavelmente vem sendo ressaltada e com objetivo: propriedades declaradas de forma “inline” dificultam a manutenção de website, deixam o código carregado de informações não relevantes para mecanismos de busca e para leitores de tela além de, devido este tipo de declaração ter maior relevância na renderização realizada pelos browsers, o que é declarado “inline” vai sobrescrever o que foi declarado nas folhas externas, fazendo com que você se obrigue a utilizar hacks, ou seja, um “conserto” atrás de outro.
Reforçado o recado continuamos, para estruturação inicial de uma interface, podemos criar uma folha de estilos com as propriedades básicas (diagramação de sustentação dos 3 principais elementos), reset nas pré-formatações de alguns elementos (já comentado em outro artigo) e declaração dos estilos dos elementos de repetição do projeto (elementos de topo, menus, breadcrumbs, etc). Esta folha de estilo, por exemplo, chamaremos de: estrutura.css.
Para as demais páginas, além da “home”, caso seu projeto seja um projeto de médio a grande porte (websites institucionais, e-commerces e portais) uma dica é o uso de, além da folha de estruturação, uma folha para cada página com suas respectivas propriedades. Por exemplo: home.css, noticias.css, empresa.css, etc.

Visualize a interface em blocos

Após estabelecer os principais elementos e determinar as folhas de estilos externas que serão criadas, as primeiras declarações css serão feitas a fim de criar uma estrutura de sustentação do website e com a estrutura principal pronta, podemos iniciar a inserção das demais informações que estão atreladas à estes elementos, por exemplo, no elemento topo podemos ter um menu, mas só iniciaremos sua codificação após diagramar o topo do website e verificá-lo em todos os browsers possíveis. Esta prática facilita a visualização da interface em blocos e a hierarquia que pode ser criada entre eles; hierarquia esta que pode ser traduzida nas folhas de estilo que permitem propriedades herdadas entre classes e ID’s, traduzindo esta prática em velocidade na determinação das características visuais do projeto.

Outras pessoas podem fazer a manutenção de seu código?

Iniciada a codificação da interface, esta última prática servirá principalmente para os casos de trabalho em equipe. Se sua resposta foi “sim” para a pergunta acima, reforçamos o uso de comentários tanto nas estruturas html quanto nas estruturas css, separação de imagens por pastas, folhas de estilos diferenciadas e etc. Se sua resposta foi “não”, ainda assim reforçamos o uso das possibilidades citadas acima, em prol das boas práticas entre profissionais Front-End.

Portanto, comente seus código, se organize para estruturar informações e crie métodos, pois você com certeza perceberá, mais velocidade, facilidade de manutenção e mostrará a diferença entre profissionais Front-End e o “amigo do sobrinho que faz sites”.

Por Thaiana Poplade

Graduada em Comunicação Social habilitada à Produção em Mídia Digital, atualmente busco as oportunidades nos negócios on-line, a constante evolução no desenvolvimento web e o pote de ouro ao fim do arco-íris. Sou curitibana, viciada em internet, filmes, música e conversas intermináveis. @thaipoplade

http://www.thaianapoplade.com/blog

Veja os outros posts de

  • http://www.ederprado.com Eder Prado

    Muita gente sabe disso, o problema é na hora de fazer mesmo.
    Creio que nego pensa que se fizer isso vai quebrar as mãos.

  • http://marcusgrussner.com Marcus Grüssner

    dicas simples mas que, sem dúvida, tornam o desenvolvimento de qualquer projeto o menos estressante possível!
    ótimo artigo! =D

  • Kaleb Martins

    Perfeito!! parabéns!

  • Pingback: Tweets that mention Boas práticas na estruturação de interfaces. | Tableless - Desenvolvimento com Padrões Web -- Topsy.com

  • http://www.rafaelsiqueira.com.br Rafael Siqueira

    Muito bom artigo. Se ficarmos atentos a essas e outras boas práticas na estruturação de interfaces, economizaremos tempo e faremos de forma estruturada.

    Parabens.

  • http://www.chrisb.com.br Chris Benseler

    Simples e bacana, vale pra quem está iniciando nessa área :-)

    PS: eu só trocaria no exemplo o us das divs com id de header, footer, etc… por elementos do Html 5!

  • Gui Premonsa

    @Chris: O elemento Section não deve substituir DIVs. Ele só é usado quando preceder um nível de Heading e for melhor do que usar Article, Aside ou Nav.

  • http://meadiciona.com.br/adrianocaramello Adriano Caramello

    Dois pontos que o texto destaca muito bem, além dos outros que são tão importantes quanto:

    > “muitos desenvolvedores Front-End acabam por utilizar suas próprias lógicas de estruturação” … “adotando os métodos utilizados na empresa” talvez ter uma boa documentação…

    > “Outras pessoas podem fazer a manutenção de seu código?”, em certas ocasiões como é ruim dar manutenção em códigos de outros desenvolvedores…

    Lógico que não devemos generalizar… excelente artigo, parabéns!!!

  • http://www.igorikeda.com Igor Ikeda

    Ótimo post! Boas práticas sempre são bem vindas em qualquer etapa de trabalho!

  • http://www.kadunew.com/blog/ Carlos Eduardo

    Organização em um projeto é tudo.
    Parabéns, artigo perfeito!

  • http://yuri.gs Yuri Goytacaz

    eu ainda prefiro usar “cabecalho” ao invés de “topo”. afinal, header é cabeçalho, né? (=
    parabéns pelo texto.

  • http://www.cahfelix.com.br Cah Felix

    Parabens! Muito Bom!

  • charles lins

    Sempre quis usar as CSS em separado, por páginas e assim, facilita muito encontrar os elementos.
    Mas esta opção não sobrecarrega o acesso ao site, tendo que requisitar vários CSSs?

  • http://jamesclebio.com.br James Clebio

    Trabalho basicamente dessa mesma forma e recomendo a prática! Porém, prefiro não usar o CSS Reset em “estrutura.css”, como sugere a Thaiana. Costumo usá-lo como um arquivo externo, usando media=”all” na tag link. Com isso, posso usar essas mesmas declarações de reset para outras medias (print, etc.) sem duplicar código…

  • http://vitoleandro.wordpress.com Leandro Vitor

    CSS inline é, a meu ver, o que deixa o código sujo e feio, além de dificultar e muito na manutenção. Sempre fui adepto de ter um css para cada página, o que deixa meu código limpo e simple de fazer manutenção. Gostaria de lhe dar os parabéns pelo belo artigo e a partir de agora sou seguidor desse site !

  • http://www.guilhermeventura.com.br Guilherme Ventura

    Bom artigo, porém discordo do amigo Eder Prado.

    Realmente, muita gente sabe, mais implementar isso no projeto nem sempre é algo viável, já passei por muitos casos onde OU eu estruturava o projeto de forma correta e semântica , OU eu entregava no prazo e mantinha meu emprego.

    A verdade é que SIM , estruturação semântica evita problemas com manutenção, mas leva algum tempo a mais pra montar, por maior que seja a experiência do programador em questão.

    Claro que nem sempre é por motivos de prazo curto, existem (e muitos) desenvolvedores preguiçosos com relação a boas práticas, mais cada caso é um caso.

    Mas enfim, não deixemos de espalhar as boas práticas por ai, e que a web se torne mais e mais semântica!

    Abraços.

  • http://www.cofres24horas.com.br cofre 24 horas

    costumo desenvolver em photoshop e depois css ajuda bastante.

  • estenio

    Ja fiz sites de tudo quanto é tipo, diversa coisas aconteceram no decorrer delas e são essas coisas que não vai estar em nenhum post pois são situações na qual deve passar para aprender.

    Para projetos grandes eu uso o método com uma folha de estilo principal e as outras para suas respectivas seções. Ainda não uso HTML5 pois há muitas limitações e muitos clientes ainda usam por exemplo ie7.

    Outra coisa importante é ter um padrão, e isso vem do layout ja pois se a pessoa for programar algo com grande contéudo por exemplo o site não pode conter muitas firulas e deve ter um padrão em cada parte dela.

    hoje em dia uso png sem dó, o que facilita muito o trabalho mas se precisar programar para ie6(sem usar hacks)nós programamos, claro a um custo maior é isso ai hehehe

  • Eduardo de Azevedo

    Interessante o seu post, Thaiana.

  • Juarez P. A. Filho

    Seria interessante em cada artigo do Tableless ter uma característica informando o nível do artigo. ;) Esse artigo é bem para iniciante, não deixa de conter dicas interessantes, mas se um profissional está na área há mais de 1 mês e não aprendeu essas dicas básicas, tenho só a lamentar pelo futuro desse profissional.

  • Leonardo A. Souza

    “Todo mundo” faz isso, mas convém indagar:

    Por que não usar section#content no lugar de um div#content?

  • gustavo

    isso é o mínimo das boas práticas de html/css, quem não o segue está fadado ao erro e ineficiência

  • http://www.construsitebrasil.com Márcio

    Realmente ajuda muito. O difícil agora é mudar a mentalidade para todos implementarem isto.

  • http://www.semitom.com.br Anderson

    Thaiana Poplade me tire um dúvida existe alguma diferença em adicionar o css em apenas uma folha de estilo e adicionar em várias…
    por exemplo se eu crio um style.css e dentro dele defino o estilo de todas as páginas isso me gera alguma vantagem sobre criar um estilo diferente para cada página?

    Parabéns pelo post muito bom!

  • Pingback: Boas práticas na estruturação de interfaces | Blog do Expert

  • Pingback: Quer ser bla bla bla? | Fabricio Sites

  • Pingback: Quero ser Desenvolvedor FrontEnd | Fabricio Sites

  • http://wendesign.com.br wenderlan

    Boas práticas na estruturação de interfaces é tudo, mas eu discordo em um ponto, no que você sugere em dividir os estilos css em vários arquivos, nem sempre fica mais fácil encontrar o que deseja em estilos separados, além de gerar várias requisições desnecessárias no servidor deixando o carregamento do site mais lento, acredito que um estilo bem comentado facilita muito mais a vida de quem trabalha em equipe, além de não prejudicar o desempenho na renderização do site.

  • http://www.lucastomkiel.com.br/blog Lucas Tomkiel

    Muito bom mesmo !