Advertisement
  1. Web Design
  2. HTML

Desenvolvimento para Designers: Entendendo o Front-end

by
Read Time:9 minsLanguages:

Portuguese (Português) translation by Erick Patrick (you can also view the original English article)

Nesse artigo, falaremos bastante sobre desenvolvimento front-end e veremos sua posição no geral. Eis o que cobriremos hoje:

  1. Entendendo a pilha tecnológica do front-end
  2. Limitaçãoes da DOM
  3. Considerações
  4. Entender eventos, estados e responsividade

Entendendo a Pilha Tecnológica do Front-End

Renderizar site pode ser difícil. Com inúmeros aparelhos, navegadores, pontos de acesso, larguras de banda, linguagens de programação e ambientes, criar experiências web consistentes pode ser difícil. Graças aos navegadores e o corpo padronizador (W3), temos alguns pilares para controlar as possibilidades. Os pilares são o HTML, CSS e JavaScript.

Combinados, são a pilha tecnológica do front-end. Cada linguagem tem seu propósito e os desenvolvedores passam muito tempo garantido que elas não se misturem muito. Logo, fiquemos no básico. Navegadores modernos, disponíveis comercialmente, como o Safari, Edge, Chrome e Firefox, podem entender apenas HTML, CSS e JavaScript. Só isso, três linguagens. Com exceção do JavaScript, HTML e CSS são linguagens estáticas declarativas. Com isso, queremos dizer não "programamos" de verdade com elas, já que não há lógica a criar (com algumas exceções). JavaScript, que "explodiu" em cada canto da internet nos últimos anos é, contudo, uma linguagem de programação.

Ao explicar a pilha tecnológica do Front-end para estudantes no passado, usar uma analogia do corpo humano saiu-se bem. Considerando que falamos no contexto do Design Atômico, coincidentemente, a metáfora se mantém!

Um corpo, ontem

HTML: Linguagem de Marcação de Hiper Texto

HTML é nosso esqueleto. Ele determinar nossa estrutura e postura. Um certo nível de significado deriva de tal estrutura. Nossa cabeça sempre vem primeiro, daí pescoço, peitoral, quadril, pernas, pés e vai até as falanges.

HTML, eca

A ordem dos elementos que descrevemos é o típico humano. Pode ser diferente para uma baleia ou tigre. Assim, o HTML pode ser diferente para blogs, lojas online ou plataformas. HTML é significado, descrevendo ao navegador de forma compreensível sobre o que uma página é. Virou ciência, ultimamente, já que o algoritmo do Google, essencialmente, lê essa estrutura e deriva dela o "significado" da página.

Aprendizado: ter em mente que o HTML prvê a estrutura para a experiência web.

CSS: Folhas de Estilo em Cascata

CSS é nossa aparência. Cor do cabelo, olhos e pele, pelos, cumprimento dos braços e dedões, músculos, etc. É até o jeito que arrumamos nosso cabelo ou a maqueagem que usamos para sermos quem somos.

Seu único propósito é estilizar o que seria um HTML bem chato. Se aparentássemos ser apenas esqueletos, atração seria bem diferente. O mesmo se aplica a experiências web.

JavaScript

JavaScript são nossos maneirismos e interações. Desde o estalar dos pulsos a piscadelas, sorrizos, tosse, o jeito de caminhar, se decidimos passar ou não, tudo é interatividade. O importante a lembrar sobre JavaScript é que ao fecharmos o navegador, tudo é esquecido (em geral), assim, podemos pensar no JavaScript como a interatividade em um site durante uma "sessão" ou ativo nele. Algo como clicar em popups ou menus suspensos.

Isso é alguém caminhando

Alguns devem estar pensando one o cérebro e a "lógica" entram, mas já chegamos lá. O mais importante e lembrar dessa seção é que HTML, CSS e JavaScript vivem no navegador, todos trabalham juntos para criar uma experiência "estática" que podemos levá-las para o Design Atômico e refinar.

Limitações da DOM

DOM vem de Document Object Model. A DOM é o resultado ao vivo do HTML, CSS e JavaScript co-existindo em uma sessão ativada pelo usuário.

Pela DOM ser uma representação ao vivo do código fonte, é importante entender que ela tem limitações. O código escrito nos arquivos HTML, CSS e JavaScript que ficam no computado é chamado de código fonte. Esse fonte basicamente imita o que vemos na DOM, embora não seja a mesma coisa. A DOM é o profuto final após a manipulação e conferência desses arquivos fonte. Quando eles são requisitados pelo navegador, as linguagens são "interpretadas" e um site ou página nasce. Se mudarmos o código fonte, a representação deles precisa ser atualizada para mostrar a versão atualizada no navegador.

Cada linguagem tem suas limitações. CSs por exemplo, não tem um mecanismo de layout muito forte. Isso significa que pode ser bem trabalhoso criar layouts complexos no navegador. HTML não tem capacidades de layout e apenas é capaz de prover a estrutura da hierarquia para o site ser entendido. JavaScript, sendo uma linguagem de programação, tem a capacidade de manipular HTML e CSS. Por usarmos uma pilha tecnológica de três camadas para criar o front-end de qualquer site, eles precisam trabalhar bem juntos, além de conformar com alguns parâmetros extras. No nosso caso, esses parâmetros são os diferentes navegadores, dispositivos, sistemas, versões e mais. A DOM é mais ou menos a mesma pelos navegadores e distribuidores, mas, por isso, temos várias regras para aderirmos para criarmos uma experiência consistente.

Considerações

CSS aplica um conceito chamado Modelo da Caixa. Esse modelo abrange as seguintes propriedades:

  • Conteúdo: a área atual de conteúdo, preenchida com texto
  • Espaçamento: espaço extra que circunda a área de conteúdo e aumenta o plano de fundo
  • Borda: uma borda, além do espaçamento
  • Margem: separa a forma de outros elementos

Eis um diagrama que explica um pouco melhor.

Pequenas caixas, na encosta

Ao projetar uma forma tal qual um quadrado, o espaço real que ele toma abrange esses elementos acima.

"As chances nunca estão a seu favor"

Sim, grades de cinco colunas caem bem com desenvolvedores. É mais fácil trabalhar com números pares que ímpares. Desenvolvedores tendem a usar frameworks front-end como Bootstrap ou UiKit que vem com grades pré-calculadas de dez, doze ou mais colunas. É sempre bom perguntar qual framework está no plano de uso, se existir, para alinhar o design apropriadamente com o HTML e CSS.

Água, Não Gelo

Já se foram os dias da velha web. Como a maioria dos sites buscam a responsividade, a necessidade de layouts fluidos tem ficado aparente. Grades agora são criadas com percentuais (10%, 30%, 50%) dos containers, que, então, se rearranjam em certos pontos de paradas especificados.

Fontes Não São Nossas Amigas

Fontes em sites são bem diferente do impresso. Ao construir nossos sites no nosso computador, podemos usar qualquer fonte instalada nele. Isso é ótimo para nós, mas quando esses arquivos vão para outro computador, o código não consegue referenciar aquela fonte que temos instalada, logo não conseguirá alcançá-la.

Há muitas formas de resolver esse dilema, mas no geral vemos desenvolvedores pedindo designers para usar Google Fonts. Google Fonts é conjunto de fontes hospedado numa CDN, acessível por qualquer computador com internet, permitindo que, mesmo que não tenhamos a fonte instalada localmente, ela ainda poderá renderizar no site. Lembremos disso. Algumas fontes também não são projetadas para renderizar nos motores web. Elas podem parecer muito diferentes quando vistas no Photoshop comparando ao navegador. Cada programa renderiza fontes de maneiras diferentes, com motores diferentes.

Eventos, Estados e Responsividade

Agora que cobrimos parte do básico, vejamos alguns problemas que designers não costumam considerar nos projetos mas são muito importantes para a experiência do usuário.

Eventos

Events são ações que um usuário toma ao interagir com um site. JavaScript possui vários, mas exemplos simples incluem "click", "scroll", "mouseon" ou "mouseout", e "keydown" ou "leyup". Se quiser saber mais sobre eventos no JavaScript, visite a Mozilla. Alguns eventos que virmos aqui não são, necessariamente, ativados por ação do usuário.

Na perspectiva de um designer, pe primordial entender o que acontece a certos elementos ou seções de um site após um usuário agir sobre eles. O que acontece quando um botão é clicado, por exemplo? Ou há alguma animação aplicada a uma janela modal quando fecha após clique? Precisamos prover respostas para essas perguntas, especialmente se o projeto tiver um escopo pré-definido. Dependendo do orçamento e tempo, "Design de Interação", como dito nas comunidades web, pode levar bastante tempo do projeto.

Estado

Após um evento, elementos são deixados em "estados". Um exemplo disso são links. Links tem um conjunto de estados: active, focus, hover. Como nossos links se parecem ao serem clicados? Quando são pressionados? Quando o mouse se sobrepõe a eles? Ou quando são tocados?

Design Atômico é muito útli aqui já que nosso guia de estilo pode, facilmente, levar em conta esses estilos ao criar um átomo como um botão. Estado tem um grande impacto na experiência do usuário, então, levemos em consideração ao lidar em sites mais complexos.

Responsividade

O termo "responsividade" tem chamada atenção há um bom tempo. Como desenvolvedores, precisamos garantir que nossas experiências web sejam consistentes entre dispositivos. Se somos freelancers, quase todo cliente pedirá para seus sites serem responsivos. Tornou-se o "pão com manteiga" da web. CSS provê os desenvolvedores tecnologias úteis como Consultas de Mídia, que permitem-nos customizar layouts em certos "pontos de parada".

Frameworks front-end, como Bootstrap e Foundation são orientadas a tornar responsividade mais fácil de implementar, inventando grades responsivas baseadas em percentuais para desenvolvedores usarem. O aprendizado não é como o design responsivo funciona, mas para o que eles são projetados a fazer.

Conclusão

Acabamos por hoje! No próximo artigo veremos o backend e como usar a mentalidade do Design Atômico para aprimorar nosso entendimento de lógica e habilidades programáticas.

Advertisement
Advertisement
Looking for something to help kick start your next project?
Envato Market has a range of items for sale to help get you started.