Bom web design responsivo, por sua natureza, passa despercebido para aqueles que consomem conteúdo online. Por isso, quando alguém pede um novo site, muitas vezes não tem consciência do conceito, apesar de o experimentar diariamente. E, no entanto, o design responsivo do site agora é reconhecido como prática padrão em todo o setor.
A criação de sites responsivos alterou nossos processos, desde a criação de modelos de páginas completas até a criação de bibliotecas de componentes e layouts reutilizáveis.
o layout é orientado por conteúdo e os estilos são orientados pela marca
Recentemente, fomos abordados por um cliente existente para redesenhar seu site de maneira responsiva. Anteriormente, trabalhávamos com eles usando um processo de cascata rígido. Passando para um fluxo de trabalho ágil, conseguimos adotar a mudança em qualquer ponto do projeto.
Ao longo do processo, aderimos à filosofia de que o layout é orientado por conteúdo e os estilos são orientados pela marca.
Os documentos de especificação funcionam muito bem para listar todas as funcionalidades que um site precisa ter. Mas é realmente o que o cliente precisa? É muito difícil visualizar esses recursos no lugar. Assim, o resultado é que documentos de especificação frequentemente se transformam em listas de desejos inchadas. Isso não ajuda o cliente, os designers ou o site final.
Em vez de documentos de especificação, optamos por usar armações de arame. A primeira etapa do projeto envolveu a criação de estruturas de arame para cada página. Isso pode soar como um exagero, mas as molduras de fios levaram a discussões iniciais do conteúdo e dos recursos de cada página. Descobrimos que recursos que nunca consideramos antes foram adicionados, enquanto muitos foram removidos.
As molduras de arame nos forneceram uma representação visual clara de como o conteúdo e a funcionalidade devem ser priorizados em cada página. Essas estruturas de arame então se tornaram um ponto de referência, substituindo um documento de especificação.
Conclusão fundamental: a produção de molduras de arame no lugar dos documentos de especificação enfoca todo mundo nas principais características e na importância do conteúdo.
A auditoria das estruturas de arame nos permite formar uma lista de todos os componentes comuns. Em um único site, haverá dezenas de pequenas seções em cada página que são muito semelhantes. Esses componentes podem ser agrupados em uma lista exaustiva que será usada posteriormente.
Esta fase tem três benefícios principais:
Principais argumentos: planejar como abordar o desenvolvimento de front-end de um projeto é importante para criar uma base de código enxuta e sustentável.
Bibliotecas de padrões são uma coleção de elementos comuns usados em um site. Ao concentrar o desenvolvimento de front-end em componentes de construção que não são dependentes de páginas, podemos reduzir a sobrecarga de código e melhorar a consistência.
Usando a lista de componentes que reunimos durante o estágio de auditoria, podemos estruturar nosso Sass em uma coleção gerenciável de arquivos.
Usamos bibliotecas de padrões em alguns projetos, mas sempre lutamos com convenções de nomenclatura, particularmente a estrutura de pastas: onde você coloca seus estilos para este reprodutor de música, em componentes ou em partições?
Anteriormente, estávamos usando terminologia, como parciais e componentes, para organizar nossos arquivos Sass. Embora pareçam convenções de nomenclatura completamente legítimas, elas estão abertas à interpretação. Quando há vários desenvolvedores trabalhando em um projeto, deixar a organização da base de código aberta à interpretação leva ao CSS desorganizado.
O BEM (Block, Element, Modifier) nos fornece uma convenção comum a seguir e cria um entendimento entre os desenvolvedores front-end. A maneira antiga foi deixada para os desenvolvedores individuais para chegar a nomes de classe que eram todos muito alto nível para obter qualquer significado. Felizmente tivemos a sorte de ver Brad Frost falar sobre sua biblioteca padrão no Conferência inicial Em Manchester. O Pattern Lab empresta terminologia da química para descrever os componentes que compõem a biblioteca. O uso de átomos, moléculas e organismos para descrever as diferenças entre componentes em uma página ajuda a explicar o conceito para os desenvolvedores novos no projeto.
O design atômico é para interfaces de usuário: http://t.co/eEZSYeK5VF Você pode aplicar o design atômico a qualquer interface do usuário, como o Instagram pic.twitter.com/BrztgtRoGU
- Brad Frost (@brad_frost) 10 de julho de 2015
Na natureza, os átomos são a menor denominação (a menos que nos aprofundemos em quarks e elétrons). No desenvolvimento web, os átomos são os elementos mais básicos do HTML. Para todos os efeitos, eles não fazem muito por conta própria. Estes incluem cabeçalhos, parágrafos, entradas, botões, listas… Você entendeu.
Estas são as próximas camadas. Em química, as moléculas são compostas de átomos e o mesmo se aplica à estrutura do CSS. Moléculas são componentes do site que usam átomos para formar eles.
Um bom exemplo de uma molécula é uma caixa de pesquisa. Isso contém 3 átomos: um rótulo, entrada e botão. A camada da molécula começa a formar alguns dos elementos que podemos usar no site. É importante tornar todas essas moléculas escalonáveis. Eles devem ser projetados com a idéia de que poderiam ser usados em qualquer lugar do site. Nosso objetivo final é tornar o CSS o mais flexível e reutilizável possível.
Como o nome sugere, os organismos são agrupamentos de moléculas. Alguns exemplos incluem um cabeçalho, rodapé ou lista de produtos.
Se tomarmos o exemplo de um cabeçalho, isso incluiria um logotipo, uma pesquisa e uma navegação. Estes foram todos criados como moléculas e são combinados para formar um organismo de cabeçalho.
É aí que a analogia da bioquímica termina. Como Brad diz, "entrar em linguagem que faz mais sentido para os clientes e saída final" . Modelos são a cola de um site. Estes combinam todos os organismos que criamos em um layout que pode ser aplicado a uma página no site.
Um exemplo poderia ser uma listagem de blog. Esse modelo incluiria um cabeçalho, um rodapé, uma lista de itens do blog e uma barra lateral. Os modelos são geralmente estruturais, contendo apenas o layout.
A seção final é páginas. É aqui que você pode testar os modelos com dados reais. Páginas são instâncias específicas de um modelo. Esta parte é importante porque nos permite ver quão bem sucedidos os átomos, moléculas, organismos e modelos foram.
É inevitável que, ao criar o site, alguns cenários sejam perdidos. O exemplo clássico é títulos longos, ou catering para diferentes moedas e idiomas.
Key takeaway: Convenções de nomenclatura são importantes. Layering CSS cria uma base de código limpa para trabalhar a partir do menor tamanho possível.
Projetar padrões é difícil. Você não pode criar um padrão isolado, como um item de notícias, e esperar que ele se encaixe no restante da página. A maneira como construímos sites e a maneira como os projetamos diferem.
É provável que os projetos mudem, independentemente de termos sido aprovados ... A saída se tornou um passo irrelevante no processo, que apenas pressionou os dois lados
Usamos o Photoshop para criar maquetes das estruturas de arame com esses componentes estilizados no lugar. Uma vez que ficamos felizes com a aparência dos designs, passamos a isolar cada componente. Isso nos permitiu garantir que cada componente fosse flexível o suficiente para funcionar em qualquer lugar do site.
Estávamos muito conscientes de não conseguir aprovação em nenhum trabalho de design. A aprovação do design cria uma barreira onde o designer se sente pressionado a criar algo que será gravado em pedra. É provável que os designs mudem, independentemente de termos ou não assinatura. Geralmente ficamos felizes em acomodar quaisquer alterações em qualquer ponto do cronograma do projeto. A assinatura tornou-se um passo irrelevante no processo que apenas pressionou os dois lados em detrimento do relacionamento.
Saber quando passar do Photoshop para o código é importante. Este passo é muito mais cedo do que estávamos acostumados por dois motivos:
Em vez de gastar mais tempo no Photoshop, optamos por investir o tempo no código. Se devemos aperfeiçoar qualquer coisa, deve ser o código, o bit que realmente será usado e visto por todos os usuários do site. Para nós, o Photoshop foi uma ferramenta para criar um estilo de design que poderia ser usado em todo o site.
Design é muito mais sobre colaboração entre todos da equipe. Mockups ainda eram uma parte muito importante do processo, ajudando o cliente a visualizar a aparência do site. Se estivéssemos todos felizes com a direção geral do design, passaríamos para o código. Raramente passamos um tempo indo para trás e para frente, corrigindo os documentos do Photoshop.
Key takeaway: Photoshop é uma ótima ferramenta para criar conceitos de design. Migrar para o código o mais rápido possível é importante. Aperfeiçoe-o no código, não no Photoshop.
A beleza deste fluxo de trabalho é que existem muitos lugares para rever e melhorar o site.
É importante notar que estas são etapas frouxas em nosso processo de projeto. Se precisarmos de algo novo durante o projeto, geralmente o trataremos como um componente autônomo e modular que pode ser inserido no site e adotar o tema de design do site.
Cada uma dessas etapas oferece um ponto em que podemos revisar nosso trabalho até o momento. Ele também permite que um novo conjunto de olhos veja as coisas de uma perspectiva diferente.
Durante qualquer um desses estágios, podemos descobrir que algumas partes não estão funcionando tão bem quanto o esperado. Esta certo. Na verdade, é bom. Capturar precocemente a usabilidade é a chave para um site de sucesso. Retroceder e enquadrar essas partes do site tornará o projeto melhor quando for lançado.
Algo importante: não tenha medo de voltar ao começo se algo precisar ser melhorado. Pegá-los cedo tornará o projeto melhor quando for lançado.
Passamos dias trabalhando juntos para garantir que todas as partes do site tivessem um alto padrão. Testamos o maior número possível de cenários, garantindo que a experiência de navegação fosse consistente.
Quando os dados estiverem no website, poderemos testar totalmente o site. Muitas vezes é muito fácil definir um projeto ao vivo sem testar completamente. Podemos verificar a velocidade, a facilidade de navegação e, mais importante, o fluxo de compras.
Todos mencionam a Apple por serem perfeccionistas, mas tenho certeza de que suas primeiras tentativas estavam longe de serem perfeitas. Leva tempo e dedicação para fazer essas melhorias finais para nos dar os produtos que amamos hoje. Usando o nosso laboratório de dispositivos, que inclui a maioria dos dispositivos e plataformas populares, conseguimos garantir que a experiência fosse otimizada em tantas plataformas e tamanhos de tela quanto possível.
Aprender com cada projeto é importante para que possamos melhorar continuamente os processos que levam a melhores sites.
Este projeto viu o nascimento de nossa própria biblioteca interna de padrões que incentiva a consistência entre os projetos. Ao trabalhar em uma agência, podemos ter dezenas de projetos atualmente em desenvolvimento simultaneamente. A capacidade de qualquer um trabalhar em qualquer projeto é importante.
Criar uma base na qual todos possamos trabalhar ajudará a contribuir para esse objetivo.
O desempenho do site só foi considerado no final do projeto. Um site responsivo e bem-sucedido precisa ser enxuto e rápido. A enorme variedade de dispositivos e suas capacidades variam enormemente de novos computadores Mac a smartphones antigos. Ao construir um site rico em mídia, pode ser muito difícil gerenciar o desempenho, especialmente quando se tenta, retrospectivamente, melhorá-lo.
Na Conferência Upfront em Manchester, vimos Yesenia Perez Cruz falamos sobre considerar o desempenho em todas as etapas de um projeto, incluindo o design. Em retrospecto, isso é algo que deveríamos ter implementado. Como uma equipe de vários designers, desenvolvedores e desenvolvedores de front-end, o gerenciamento do tamanho e do desempenho gerais (principalmente o desempenho percebido) deveria ter sido uma prioridade maior.
Tudo em uma página tem um custo por desempenho. Priorizar o que é importante garante que o site não seja apenas rápido, mas acessível a mais dispositivos. Em alguns dispositivos mais antigos, descobrimos que o site não caiu apenas no navegador, mas no dispositivo inteiro. Tentar acelerar o site retroativamente significava que não poderíamos criar o site o mais rápido possível.
Da próxima vez, garantiremos que o desempenho seja incorporado em todas as etapas do processo, por isso não é uma reflexão tardia.