aguarde...

29 de agosto de 2019

Ainda deveríamos estar vendendo web design responsivo?

Ainda deveríamos estar vendendo web design responsivo?

O termo ‘web design responsivo’ é um dos pilares do mundo do desenvolvimento digital há muitos anos . Vá a qualquer reunião inicial do cliente e quase sempre será solicitado que você ‘verifique se ele funciona no celular’.

A resposta padrão a isso geralmente é: ‘não se preocupe, nós a construiremos responsiva’, mas essa resposta está desatualizada?

As limitações do web design responsivo

A principal ‘ferramenta’ de web design responsivo é a ‘consulta de mídia’. Isso nos permite aplicar um subconjunto de CSS somente quando um site é renderizado em um tamanho, orientação específica ou quando algum critério ambiental escolhido é atendido (por exemplo, nível de luz ). Isso permite que um desenvolvedor front-end manipule facilmente como um site, produto digital ou aplicativo é exibido em dispositivos de tamanhos diferentes ou quando o tamanho da janela é alterado.

No entanto, estou começando a pensar que as regras de vinculação sobre como um elemento deve ser exibido para o tamanho da página ou dispositivo geral são míopes. Isso é especialmente verdadeiro no mundo atual do design orientado a componentes.

Design orientado a componentes muda tudo

Hoje, no design moderno da Web, geralmente construímos componentes independentes do ambiente, altamente reutilizáveis, usando metodologias como o Atomic Design , geralmente com o objetivo de criar uma biblioteca de padrões para ser usada em diversas aplicações. Essa abordagem economiza tempo e dinheiro, pois reduz a necessidade de duplicar o trabalho. No entanto, existe um ônus, pois cada componente individual precisa ser robusto o suficiente para funcionar adequadamente quando descartado em recipientes de tamanhos diferentes.

Por exemplo, se construímos um componente de visualização de item de notícia, com uma imagem acima de um trecho de texto, ele pode ser exibido em um contêiner amplo (por exemplo, uma página de índice) ou em uma barra lateral (por exemplo, artigos relacionados). Se escrevermos uma consulta de mídia que altere a exibição do item de notícias com base no tamanho da janela de visualização (por exemplo, colocando a imagem ao lado da cópia em vez de acima dela), limitaremos os contextos quando esse item for útil. Isso ocorre porque, se a viewport for ampla, a regra será aplicada, mesmo que o componente esteja sendo usado na barra lateral, onde não há espaço suficiente.

Este é o cerne da minha reclamação; consultas de mídia são muito manuais e explícitas. Em vez de definir o estado ideal para um componente, somos forçados a colocá-lo em contexto e testar como ele funciona em relação à tela e, em seguida, ajustar manualmente. Se você for como eu, você estará fazendo o ajuste óptico e depois explicitamente escrevendo regras para ajustar a exibição ao seu gosto. Se o layout da página mudar – e, portanto, como o módulo fica na página – você provavelmente terá que reavaliar essas regras. Isso cria uma enorme carga de manutenção e facilita a quebra visual dos componentes em determinados tamanhos de viewport, sem o conhecimento da pessoa que faz as alterações.

O design responsivo da web, até o momento, preocupou-se com a tela, mas o que é realmente necessário é uma mentalidade orientada a componentes.

Web design intrínseco

Em 2018, a advogada Mozilla Designer Jen Simmons cunhou o termo web intrínseco. Essa metodologia adota uma abordagem mais abrangente para o design digital. Em vez de alterar os estilos com base no tamanho de uma janela de visualização (ou no tamanho da tela do dispositivo), os componentes se organizam automaticamente com base em suas próprias condições ‘ideais’.

Por exemplo, em vez de dizer com 768px de largura, a imagem do artigo de notícias fica acima do texto, e não ao lado dele, poderíamos fornecer diretrizes mais aproximadas: ‘a imagem deve abranger toda a largura do pai, mas, idealmente, não deve ter mais do que 250px de largura ‘ Quando a imagem atingir 250px, ela se moverá automaticamente para ficar ao lado do texto.

Podemos descrever o design responsivo / adaptável como uma abordagem imperativa – você está descrevendo um comportamento explícito para ocorrer em uma largura explícita. O design intrínseco, entretanto, tem mais em comum com uma abordagem declarativa; estamos fornecendo diretrizes, mas deixando a implementação precisa para o navegador.

Layout de caixa flexível, grade e várias colunas

O design intrínseco é amplamente ativado por novos métodos de layout (ish), como CSS Flexbox e CSS Grid (usando o layout automático). Todas essas são tecnologias complementares e não se substituem – a grade é bidimensional, o Flexbox é unidimensional.

Abaixo está um exemplo de como podemos usar o CSS Flexbox para criar um componente sem consulta de mídia que se adapta automaticamente:

ul {
    display: flex;
    flex-wrap: wrap;
}

li {
    flex-grow: 1;
    flex-basis: 250px;
}

Isso significa que, quando os itens da lista ficarem menores que 250px, eles deverão ser agrupados. 250px é o tamanho ‘ideal’, mas eles podem crescer para preencher espaço adicional.

Aqui está um exemplo adicional com CSS Grid :

ul {
  grid-template-columns: repeat( auto-fit, minmax(250px, 1fr) );
}

Isso significa que, quando as colunas tiverem menos de 250 px de largura, elas deverão ocupar sua própria linha. Não precisamos dizer explicitamente quando mudar o layout. Em vez disso, estamos fornecendo uma regra orientada por conteúdo. Ele não está vinculado ao tamanho da janela de exibição, mas à largura do próprio conteúdo, portanto, pode ser usado em elementos aninhados. Se a grade for usada dentro de uma pequena barra lateral, por exemplo, ela será uma única coluna, enquanto se também for usada em uma área de conteúdo próxima à barra lateral (maior que 250px * 2), será dividida em colunas.

Como alternativa, poderíamos usar o layout CSS de várias colunas com a column-widthpropriedade:

ul {
  column-width: 250px;
}

O comportamento desses três exemplos é sutilmente diferente, com variações em torno da largura dos itens de quebra automática e a distribuição depois que eles são quebrados. No entanto, a premissa é a mesma: aconselhamos a largura ideal de um elemento e deixamos o navegador se preocupar com quando e como quebrar.

Esses exemplos são ‘contextuais’ e mais ‘responsivos’ do que o responsivo web design, pois respondem ao seu ambiente, não à viewport.

Trazer consultas de contêiner

Espero que em algum momento no futuro, as consultas de elemento ou contêiner sejam introduzidas, e este post será discutido. Certamente, até esse ponto, é difícil eliminar completamente as consultas de mídia, tanto quanto eu gostaria.

Enquanto isso, é possível apontar para o trabalho inteligente que foi feito para tornar os componentes responsivos aos pais, não a largura da página. No entanto, para mim, muitas dessas soluções são restritivas de contexto.

Então, onde isso nos deixa?

Bem, não, o design responsivo da web não está morto, mas estamos no ponto em que evoluímos além do que a maioria das pessoas quer dizer quando usa o termo. Não estamos mais tentando ajustar o que fazemos a diferentes tamanhos de tela.

Em vez disso, agora estamos construindo produtos digitais de uma maneira mais flexível e orientada a módulos, e agora temos ferramentas melhores do que há cinco anos que facilitam o trabalho assim. Estamos projetando no nível modular, em vez de no tamanho da tela, e estamos adotando uma abordagem mais declarativa. Ainda é um design web responsivo, estamos apenas respondendo a um estímulo sutilmente diferente.

Posted in Blog
Write a comment