Responsive Web Design: Projetação vs Execução

Em um projeto para a web, hoje em dia, é mais do que necessário contemplar os variados dispositivos de acesso à internet, considerando suas limitações e vantagens. Desde a definição do conteúdo a ser publicado, passando pela programação visual até a implementação, deve-se ter em mente que um resultado ideal é aquele em que o usuário não precise realizar esforços diferentes para ter acesso à informação em diferentes dispositivos.

Este novo paradigma, chamado Responsive Web Design (termo cunhado por Ethan Marcotte neste artigo), trouxe desafios para profissionais de Web Design/Design Gráfico e desenvolvedores para a realização de projetos satisfatórios no que tange ao acesso à informação. Consideremos, aqui, duas grandes etapas que passam pela necessidade de atender aos requisitos e boas práticas de Responsive Web Design: definição do fluxo de informação e programação visual (Projetação); e aplicação dos resultados da etapa anterior em código utilizável para a web dentro de um sistema (Execução).      É possível acessar este conteúdo também como slides no Google Drive:http://goo.gl/8F94jA. A apresentação está aberta para comentários.

Projetação:

Esta etapa envolve, normalmente, profissionais com conhecimento de Web Design/Design Gráfico e UX. Aqui é definido o fluxo da informação e como ela deve ser apresentada ao usuário. Após as definições é desenvolvida a parte visual, desde os wireframes até os layouts finais, que deverão ser aplicados na etapa de execução.

A função desta etapa, quando se trata de Responsive Web Design, é definir como deverá se comportar a interface em diferentes dispositivos, prevendo os layouts e interações. São levados em conta fatores como tipo de dispositivo, tamanho da tela e formas como ocorre a interação.

Execução:

Os responsáveis por esta etapa são basicamente desenvolvedores front-end, embora normalmente sejam necessários conhecimentos de back-end, de acordo com o sistema onde o site será implementado. Aqui são implementados os layouts e o fluxo de informação definidos na etapa anterior em código utilizável para sistemas web.

Para um bom resultado em termos de Responsive Web Design, nesta etapa deve ser aplicado o resultado da etapa anterior de acordo com o que foi considerado para diferentes dispositivos. Isto implica num conhecimento mais técnico sobre tais dispositivos, pois o código deve ser adaptado de acordo com as diferenças identificadas.

Onde ambos se encontram:

Nem sempre a programação visual desenvolvida na etapa de projetação corresponde a todo o espectro do resultado final. Normalmente são previstos layouts considerando os dispositivos computador, tablet e celular, mas são layouts estáticos (3 ou 4 layouts, basicamente). Se, na fase de execução, forem levadas em conta boas práticas de desenvolvimento para a web, os layouts além de adaptativos (mudam para o layout previsto de acordo com o dispositivo ou resolução), serão fluidos (tendem a preencher todo o espaço disponível, principalmente em telas pequenas).

Isto quer dizer que os layouts previstos na projetação vão existir, mas também vai existir uma variedade enorme de outros diferentes, porque a variedade de resoluções renderizadas pelos dispositivos é muito grande. Pode ser que a diferença visual não venha a ser muito grande, mas os casos não devem ser ignorados.

Por outro lado, na fase de execução, o desenvolvedor tem de levar em conta requisitos diferentes dos que foram levados na fase anterior, como manutenibilidade do código, performance ou compatibilidade. Com a falta de especificações técnicas em certos aspectos, a aplicação pode ter um comportamento diferente do esperado quando se pensaram os layouts.

Isto pode implicar em, pelo menos, dois problemas distintos. Primeiramente, elementos que têm seu comportamento alterado pela resolução ou tipo de dispositivo, como sua disposição na tela, por exemplo, podem ter sido pensados com tamanho fixo e aplicados com tamanho fluido. Em segundo lugar, para resolver problemas identificados nesta etapa ou para realizar alterações, corre-se o risco de que a modularidade ou manutenibilidade do código sejam comprometidas.

Como evitar problemas:

Antes de mais nada, não se pode responsabilizar uma etapa ou outra por eventuais falhas no processo, afinal o processo em si, abrangendo todas as etapas, é quem deve ser revisto. Os profissionais envolvidos numa etapa normalmente não possuem, e nem é necessário que possuam, os conhecimentos envolvidos na outra. Por isso, quanto mais os diferentes profissionais envolvidos interagirem uns com os outros durante ambas as etapas, mais segurança se tem sobre o resultado final.

Um projeto com escopo aberto pode facilitar o trabalho das partes, permitindo com que se sugiram soluções alternativas em casos específicos, a fim de não interromper ou desacelerar o andamento. É uma prática muito boa, mas que sozinha não resolve todos os problemas, pois normalmente se trata de questões identificadas já na fase de execução. O ideal seria que fosse possível evitar certas alterações.

Um código modular e com boa manutenibilidade, seguindo boas práticas das tecnologias usadas pelos desenvolvedores, pode prevenir que alterações exijam grande esforço. Contudo, isto também se trata apenas da etapa de execução, a menos que sejam seguidas especificações da etapa anterior.

O mais efetivo seria que as equipes interagissem desde o começo da fase de projetação, seguindo uma metodologia efetiva e participativa de Design. Assim, o conhecimento técnico necessário na fase de execução seria usado para prever, ainda na fase de projetação, as especificações necessárias para se ter segurança sobre o resultado final e os problemas que podem surgir durante o processo.

Aliando estas práticas, a fluidez do projeto é maior, uma vez que os profissionais envolvidos seguem uma linha de raciocínio semelhante e o trabalho de ambas as etapas é convergente com o esperado para o resultado final.