Desenvolvimento web

Desenvolvimento de site por R$150,00/Mês

Desenvolvimento Web responsivo com Melhor Custo-beneficio

Planos de desenvolvimento web com hospedagem Gratís
Arquivo de Design | LCF HOST

Design


Twitter Bootstrap

Conheça mais sobre Twitter Bootstrap e saiba como você pode desenvolver projetos mais robustos, profissionais e visualmente agradáveis com este incrível framework!

Twitter Bootstrap já não é nenhuma novidade para os desenvolvedores que conseguem acompanhar as melhores tendências e ferramentas lançadas “lá fora” por conseguirem ler em inglês e, apesar de a popularidade do Twitter Bootstrap (TB) poder contar com uma curva crescente de uso em solo brasuca, um artigo sobre este fantástico framework vem, sim, em um bom momento. Se quiser saber mais sobre o Twitter Bootstrap, continue lendo!

O que é o Twitter Bootstrap

Se você acompanha os artigos do desenvolvimento para web, deve se lembrar que em março deste ano, no artigo que comentava sobre o novo tema do blog, que uma das tecnologias usadas por aqui é o Twitter Bootstrap. Entretanto, foi só um comentário “por alto” e, neste artigo você encontrará mais informações sobre o TB.

Idealmente e tecnicamente, o Twitter Bootstrap pode ser considerado um framework. Ele é um projeto que nasceu dentro do Twitter pelas mãos dos desenvolvedores @mdo and @fat. Fato curioso é que, inicialmente, tratava-se de um esforço para documentar determinados padrões de design e UI dentro do Twitter, mas a coisa tomou proporções maiores e seus autores decidiram virar amigos da garotada, disponibilizando o Twitter Bootstrap no Github (que, por sinal, é um dos projetos mais populares de lá).

Grosso modo, o TB é um conjunto de HTML, CSS e JavaScript que proporciona uma maneira ultra-rápida, eficiente e profissional de planejar e desenvolver o front-end de web sites, aplicações, sistemas e produtos web através de seus elementos de UI e interações. Na prática, isso quer dizer que você pode “dar vida” a seus sites e produtos web em apenas algumas horas!

Através do uso de HTML5 e CSS3, os projetos feitos com TB são modernos e garantidos de serem “duráveis”. Para melhorar, o CSS é feito com LESS! E, para constar, no momento da descrita deste artigo, a versão do Twitter Bootstrap é a 2.2.0.

Principais características do Twitter Bootstrap

Como citado, o Twitter Bootstrap possui um conjunto incrível de elementos de marcação, estilo e comportamento para que dar a início a projetos de características profissionais seja uma tarefa bem simples para os desenvolvedores web.

Scafolding

Sua poderosa estrutura conta com:

  • Estilos globais que servem para todos os navegadores modernos
  • Sistema de grid
  • Sistema de grid fluido
  • Layout fixo
  • Layout fluido para web design responsivo

Projetar estruturas de layout com o TB é extremamente simples e muito rápido, já que ele já conta com alguns tipos de grid, layouts e exemplos de marcação para se começar com seu uso imediatamente! Por exemplo, ao se conhecer suas classes, ter um layout fluido é tão simples quanto:

CSS

Com o poder das classes pré-definidas do TB, é possível ter um visual incrível dos elementos de marcação mais básicos e contar com elementos de UI fantásticos. O CSS do Twitter Bootstrap abrange:

  • Tipografia
  • Código
  • Tabelas
  • Formulários
  • Botões
  • Imagens
  • Icon Fonts

Por exemplo, veja como é simples apresentar botões bonitos e funcionais apenas usando algumas classes pré-definidas:

Botõesclass=””
btn
btn btn-primary
btn btn-info
btn btn-success
btn btn-warning
btn btn-danger

Componentes

Provavelmente você nunca criou componentes tão funcionais em seus sites usando uma marcação tão simples e bem pensada, com características cross-browser e visual de encher os olhos. São eles:

  • Dropdowns
  • Grupos de botões
  • Dropdown de botões
  • Navegações
  • Barra de navegação
  • Breadcrumbs
  • Paginação
  • Rótulos e emblemas
  • Tipografia
  • Thumbnails
  • Alertas
  • Barras de progresso
  • E mais!

JavaScript

E, além de prover toda a parte visual para sua aplicação web, o TB também oferece a parte de interação destes componentes visuais! Através de seus plugins próprios para jQuery, é possível obter interações como:

  • Transições
  • Modais
  • Dropdowns
  • Scrollspys
  • Abas
  • Tooltips
  • Popovers
  • Alertas
  • Botões
  • Colapsáveis
  • Carrosséis
  • Autocompletes

É bom demais ou não é? 😉

Recursos para Twitter Bootstrap

E, se não fosse bom o suficiente, existem diversos projetos complementares ao Twitter Bootstrap para que sua força e poder de desenvolvimento seja ainda mais potencializado!

  • Globo BootstrapÉ fácil traduzir um projeto de sucesso no mundo inteiro e colocar o nome da sua marca… De qualquer maneira, está aí o Globo Bootstrap, que é a tradução do TB para a Língua Portuguesa (sinceramente, a qualidade não está tão boa e não há garantias que acompanhe as atualizações do projeto original Segundo Alexandre Magno, toda a comunidade web é bem vinda a contribuir com o projeto, inclusive traduções, e a ideia é continuar na ativa)
  • Built With Bootstrap. Uma galeria com sites feitos com Twitter Bootstrap que mostra todo o potencial do framework
  • Bootswatch. Algumas pessoas criticam que os sites feitos com o TB se parecem demais. Para os que compartilham desta opinião, não tem mais o que reclamar com o Bootswatch, que é uma coletânea de estilos para o Twitter Bootstrap
  • {wrap}bootstrap. Se quiser investir em templates prontos feitos com TB, esse é o lugar!
  • Font Awesome. Com Font Awesome é possível estender os ícones-fonte do Bootstrap, ficando com uma gama de possibilidades bem maior para compor o visual do seu site.
  • Bootsnipp. Snippets HTML grátis para várias situações comuns de UI para Bootstrap.
  • Fuel UX. Fuel UX estende o Twitter Bootstrap com controles JavaScript adicionais. Complemente as interações de seus projetos em TB com combobox, datagrid, pillbox, busca e spinner.
  • X-editable. Se você precisa de um “edit in place” em seus projetos, o X-editable vai servir perfeitamente. Ele é um edit in place para se trabalhar com Twitter Bootstrap (e possui versões para jQuery UI e jQuery puro).
  • Bootstrap Shortcodes. Para os que adoram usar WordPress (eu!), eis uma coletânea de shortcodes para implementar facilmente os elementos visuais do TB.
  • Datepicker for Bootstrap. Se faltava um datepicker para o seu projeto com Bootstrap, agora não falta mais!

Conclusão

Com Twitter Bootstrap é possível dar vida a um projeto em poucas horas, já que sua curva de aprendizado é curtíssima. À medida em que se o vai usando, mais e mais prática é adquirida e, cada vez mais, a produtividade e agilidade em desenvolver o front-end é alcançada. Este é um projeto realmente diferenciado no mundo do desenvolvimento web e seus autores, definitivamente, contribuíram de forma positiva para a melhoria e facilitação do trabalho de seus pares.


Ser um generalista não é uma coisa ruim

Já pensou em ser um profissional de web “generalista” ao invés de especialista? Leia este artigo e conheça os prós e contras dessa abordagem na carreira.

Nos últimos anos tem havido um afastamento do profissional web generalista para especialista, como estrategistas de conteúdo, arquitetos de experiência do usuário e codificadores front-end. Onde uma vez havia um único emprego, agora existem muitos, com esferas cada vez mais estreitas de responsabilidade.

Mas enquanto a maioria está se tornando mais especializada, muitos têm rejeitado a abordagem, permanecendo “generalistas” — incluindo a ampliação de seus interesses para áreas como marketing, psicologia, estratégia de negócios e outros. Não surpreendentemente, isso pode atrair críticas negativas de alguns pares que veem os generalistas negativamente.

Por que ser um “generalista” é algo ruim?

Parte da crítica se baseia na complexidade da web. Por exemplo, saber tudo sobre web designjá foi possível, mas agora é irrealista. Mas o fato de que o web design se tornou tão complexo significa que precisamos de generalistas para olhar além dos “silos de especialistas”.

O perigo é que, sem generalistas, os especialistas ficam tão envolvidos em seus silos que lhes é difícil trabalhar com especialistas em outras disciplinas. O generalista é necessário para encorajar a colaboração cruzada e para olhar além dos silos em desenvolvimentos emergentes na web.

Não confunda ser um generalista com não possuir habilidades

A percepção é que os generalistas são comuns e relativamente não-qualificados, porque todos começamos como um quando adentramos no desenvolvimento web. Mas essas pessoas não são verdadeiros generalistas.

Um generalista é alguém que é bem informado a respeito de uma ampla gama de assuntos. Isto não descreve a maioria dos desenvolvedores web — e, certamente, aqueles que estão começando. É importante não confundir ser um generalista com não ser qualificado.

Para facilitar o entendimento dos generalistas em desenvolvimento para web, alguns remetem ao termo “Pau-para-toda-obra”. Mas isso também é problemático, porque pode trazer uma conotação negativa em alguns casos. De qualquer maneira, os generalistas se sentem orgulhosos de suas capacidades de amplo conhecimento em diversas áreas.

Ser um especialista não é a única maneira de conseguir bons trabalhos

Não podemos negar que existe uma “percepção geral” de que a especialização é uma maneira muito melhor de se diferenciar em um mar de generalistas, que muitas vezes leva a empregos melhores — tanto em sentido pecuniário, quanto em satisfação pessoal.

Certamente, especializar-se é uma maneira de se diferenciar, ninguém pode negar este fato. Mas não a única maneira. Pode-se, também, confiar no trabalho de qualidade, no conhecimento de certos setores e até na amplitude da experiência e do conhecimento. Quanto aos especialistas mais qualificados para trabalhar em projetos maiores, isso também não é verdade.

Grandes projetos envolvem grandes equipes, e um generalista é muitas vezes necessário para reunir os diferentes especialistas e fazê-los trabalhar juntos de forma eficaz.

Generalistas também são chamados “passantes”, já que conseguem passar pelas diversas áreas do desenvolvimento web, facilitando a comunicação entre diferentes grupos de profissionais.

Isso significa que devemos todos rejeitar a especialização e nos tornarmos generalistas? De modo nenhum! Mas, em muitas situações, um generalista é necessário.

Você deve ser um generalista?

Como sabemos, não há nada de errado com a especialização. O que se está querendo chamar atenção é que, em certas circunstâncias, ser um generalista tem suas vantagens — e propicia vantagens para muitos profissionais trabalhando juntos num mesmo projeto web.

Aqui estão algumas circunstâncias que vêm à mente:

  • Prosperar na variedade. Generalistas têm mais oportunidades do que outros para explorar novos desenvolvimentos, técnicas e tecnologias. Se você é levado a constantemente aprender coisas e enfrentar novos desafios, então a variedade constante de disciplinas na web pode muito bem lhe servir.
  • Sua equipe de web é pequena. Pequenas equipes em grandes organizações, agências, produtoras etc, precisam de generalistas. Essas equipes exigem que todos façam o que é preciso ser feito, o que, inevitavelmente, exige que você cuide de muitas tarefas.
  • Freelancer. Trabalhar por si próprio muitas vezes exige que você seja Pau-para-toda-obra. A maioria dos clientes vai precisar de você para ajudá-los com tudo o que é relacionado à web. Especializar-se atuando como freelancer é possível, mas, certamente, não é a norma.
  • Pesquisa e Desenvolvimento. Em organizações e agências maiores, alguém precisa manter um olho em tecnologias emergentes. Enquanto especialistas vão fazer isso dentro de seus nichos, tendências inevitavelmente surgirão ao longo do tempo . O generalista será aquele que irá identificar essas novas oportunidades e avaliar quando investir nelas.
  • Você gere seu próprio negócio. Ser um generalista quando se gere o próprio negócio de desenvolvimento web não só permite se manter informado sobre uma variedade de tópicos e vendê-los aos clientes, como ajuda a entender o que as pessoas relacionadas à empresa fazem e se certificar de que as disciplinas funcionam bem em conjunto.

Enquanto alguns de nós devemos nos tornar generalistas por escolhas de carreira ou temperamento, há também boas razões para escolher este caminho em detrimento de outro.

Por que se tornar um generalista?

Os generalistas se sentem orgulhosos de suas capacidades de amplo conhecimento em diversas áreas.

Tornar-se um generalista é, em muitos aspectos, um excelente caminho a se tomar na carreira web. Para começar, ele mantém suas opções abertas: um generalista está sempre procurando novas áreas para explorar e, por isso, está idealmente posicionado para se deslocar para novos campos, como mobile ou HTML5.

Mantenha-se ágil e se adapte às mudanças

O perigo é que, como especialista, você se torna tão obscurecido por sua área de especialização que você não pode detectar novas oportunidades ou, pior ainda, não pode antecipar uma eventual retirada do mercado lenta de seu nicho. Considere aqueles que sabem como programar em nada mais que ColdFusion ou Flash… Essas tecnologias estão completamente mortas? Ainda não, mas os sinais mostram que é questão de tempo.

O potencial para mais trabalho

Ao ser capaz de se adaptar rapidamente a novas circunstâncias, um generalista raramente fica sem trabalho. Além do mais, ele pode criar a maioria dos produtos do início ao fim. Não só muitos generalistas acham isso gratificante, mas também maximiza a lucratividade, já que eles raramente precisam terceirizar. Isso está alinhado com as expectativas do cliente, que, geralmente, é que o fornecedor entregue a maioria de suas necessidades web — claro, pode haver ocasiões em que você precisa recorrer a especialistas.

Mas, antes de você resolver abandonar o caminho de ser um especialista, é justo compartilhar alguns perigos de ser um generalista.

Perigos de ser um generalista

Mais uma vez: o mote não é sugerindo que ser um generalista é certo para todos ou que algo está errado ao se especializar.  Mas ser um verdadeiro generalista não é um mar de rosas.

A luta para mostrar seu valor

Certamente, um dos maiores desafios para ser um generalista é se estabelecer como um expert e se destacar na multidão.

Generalistas muitas vezes são vistos quase como párias dos profissionais de web. Mas a verdade é que verdadeiros generalistas, aqueles com conhecimento extenso a respeito de uma ampla gama de assuntos, são muito raros. Os clientes compreendem que eles têm que pagar mais por habilidades altamente especializadas, mas não reconhecem a necessidade de pagar tanto por um conjunto amplo de habilidades diversas.

Além disso, generalistas raramente são os inovadores — se você é o tipo de pessoa que se importa com essas coisas. Eles não recebem a glória de desenvolver novas técnicas CSS ou estabelecer novos estilos de design. Em vez disso, os generalistas marcham atrás da vanguarda, selecionando os elementos que valem a pena adotar no mainstream.

A corrida constante pelo aprendizado

Generalistas continuamente têm de digerir o conteúdo de uma enorme variedade de fontes e decidir o que é de valor e o que se deve ignorar. Isso é incrivelmente exigente e, não raramente, alguma nova tecnologia ou tendência pode ser “descartada” para somente mais tarde, devido a movimentos vários da indústria, descobrir que vale a atenção.

Um generalista está sempre procurando novas áreas para explorar.

Se você não tem um perfil de ser estudioso/curioso, então ser um generalista certamente não é para você. Um generalista investe muito tempo todos os dias para ler blogs de especialistas que inovam para que possa ficar atualizado — também é preciso assimilar o que é aprendido, o que envolve tentar/testar uma variedade de técnicas.

E, certamente, algumas dessas novas técnicas podem simplesmente estar além das habilidades de um generalista.

Os limites de um generalista

Cair na armadilha de querer experimentar praticamente qualquer coisa que atravessa seu caminho é comum para um generalista. Embora admirável, essa qualidade pode acarretar prejuízo: generalistas podem desperdiçar horas tentando fazer o que um especialista poderia fazer em minutos. Pior ainda, o resultado pode ser não tecnicamente impecável e prejudicial à sua reputação.

Generalistas precisam conhecer seus limites — seja por saber quando chamar um especialista para ajudar ou simplesmente aceitar que eles não podem ser envolvidos em certas tarefas.

Conclusão sobre generalistas na web

É importante que haja um contrapeso ao impulso cada vez maior para a especialização. Mas é mais do que isso. Também é preciso haver um “respeito recém-encontrado” em relação aos generalistas: um reconhecimento de que o desenvolvimento de uma compreensão ampla dos aspectos cada vez mais complexos da web demanda tanta habilidade e esforço como se tornar um especialista em uma área.

Finalmente, este artigo também pode ser considerado um apelo àqueles que se consideram generalistas: levem seu papel a sério! Sejam generalistas verdadeiramente eficazes, que podem oferecer serviços valiosos para seus clientes e colegas e assumir compromisso de forma profissional.

Dessa maneira, certamente generalistas não ficarão carentes de bons trabalhos.


Responsive Components: uma solução para container queries

Conheça Responsive Components, uma solução para componentes responsivos que resolve o problema de Container Queries e pode ser usada imediatamente!

Você já deve ter ouvido falar em Container Queries, uma proposta que permitiria a desenvolvedores web estilizarmos elementos DOM com base no tamanho do elemento contentor (“que contém”) ao invés do tamanho da viewport do navegador. Mas já ouviu sobre Responsive Components?

Se você é um desenvolvedor a par das discussões envolvendo responsividade, provavelmente já ouviu falar sobre Container Queries antes. Desde quando toda a festa de web design responsivo começou, já havia desenvolvedores pedindo por tal recurso (inicialmente Element Queries, depois mudando para Container Queries) — de fato, Container Queries podem ser o recurso CSS mais solicitado que os navegadores ainda não têm.

Já existem muitosmuitosmuitos artigos explicando exatamente porquê container queries são difíceis de fazer no CSS e porquê os fabricantes de navegadores hesitaram em implementá-las. Essa discussão não precisa ser revivida neste post.

Ao invés de focar estritamente na proposta formal de CSS chamada “Container Queries” (Consultas de Contêiner), este artigo abordará o conceito mais amplo de construção de componentes que respondem a seu “ambiente” — responsive components. E se você aceitar esse “enquadramento” maior, realmente já existem novas APIs que permitem que se obtenha isso. Isso mesmo: não é preciso esperar Container Queries chegarem oficialmente para começar a criar componentes responsivos; é possível começar agora!

A estratégia proposta neste artigo permite o uso hoje e é projetada como um aprimoramento, então os navegadores que não suportam as APIs mais recentes ou não executam JavaScript funcionarão exatamente como fazem atualmente. Também é simples de implementar, altamente performática e não requer nenhuma ferramenta especial, bibliotecas ou frameworks.

Para ver alguns exemplos dessa estratégia em ação, existe o site de demonstração Responsive Components, em que cada exemplo aponta para o código-fonte CSS.

Mas antes de começar a realmente ver alguns exemplos, é importante saber como a estratégia proposta funciona.

A estratégia de Responsive Components

A maioria das estratégias/metodologias de web design responsivo funcionam de acordo com estes 2 princípios fundamentais (e aqui não será diferente):

  1. Para cada componente, define-se primeiro um conjunto-base de estilos genéricos que se aplicam independentemente do ambiente em que o componente esteja contextualizado/inserido
  2. Em seguida, definem-se adições ou substituições para os estilos-base que se aplicam em condições ambientais específicas

O poder desses princípios é que eles funcionam mesmo se o navegador não suportar os recursos necessários para cumprir ou permitir condições de ambiente específicas. E isso inclui casos em que o recurso requer JavaScript — usuários com JavaScript desativado obterão os estilos-base e eles funcionarão normalmente.

Na maioria dos casos, os estilos-base definidos no item “1” acima são estilos que funcionam para os menores tamanhos de viewport possíveis (uma vez que viewports menores tendem a ser mais restritivas do que as maiores) e elas não estão envolvidas com nenhum tipo de media query (o que significa que se aplicam em toda parte).

Eis um exemplo que define estilos-base para .MyComponent e depois os substituem em 2 breakpoints arbitrários, 36em e 48em:

Claro, esses breakpoints usam media queries, então eles se aplicam ao tamanho da viewport do navegador. O que os defensores de container queries procuram é a capacidade de fazer algo como isto (nota: esta é a sintaxe proposta; não a sintaxe oficial):

Infelizmente, a sintaxe acima não funciona em nenhum navegador atualmente e não funcioná tão cedo… No entanto, funciona hoje algo mais ou menos como:

Claro, este código assume que os contêineres de componentes têm as classes corretas adicionadas a eles (neste exemplo, .MD e .LG). Mas ignorando esse detalhe por enquanto, a segunda sintaxe ainda faz sentido para qualquer desenvolvedor CSS que quer construir um componente responsivo.

Quer esteja escrevendo uma container query como uma query de comparação de largura (a primeira sintaxe) ou usando classes de breakpoint nomeadas (a segunda sintaxe), os estilos ainda são declarativos e funcionalmente os mesmos. Contanto que seja possível definir breakpoints nomeados, aparentemente não há um benefício claro a favor de um ou de outro.

E para que o restante do artigo fique claro, aqui está o mapeamento das classes/breakpoints (no qual min-width se aplica ao contêiner, não à viewport):

BreakpointLargura do Container
SMmin-width: 24em (384px)
MDmin-width: 36em (576px)
LGmin-width: 48em (768px)
XLmin-width: 60em (960px)

Agora é preciso garantir que os elementos de contêiner tenham sempre as classes de breakpoint corretas; então os seletores de componentes corretos irão corresponder (match).

Observando redimensionamento de contêineres

Quase desde sempre em desenvolvimento web foi possível observar mudanças em window, mas também quase sempre foi difícil ou impossível (pelo menos de uma forma significativa) observar mudanças de tamanho em elementos individuais de DOM. Isso mudou quando o Chrome 64 disponibilizou ResizeObserver.

ResizeObserver, seguindo os passos de APIs semelhantes, como MutationObserver e IntersectionObserver, permite que sejam observadas mudanças de tamanho nos elementos DOM de uma forma altamente performática.

Aqui está um possível código necessário para fazer com que o CSS mostrado anteriormente funcione com ResizeObserver:

Este exemplo usa a sintaxe ES5 porque (como será explicado mais adiante) pode ser interessante inserir este código diretamente no HTML em vez de incluí-lo em um arquivo JavaScript externo. A sintaxe mais antiga é usada para garantir um amplo suporte de navegadores.

O código cria uma instância única de ResizeObserver com uma função de callback. Em seguida, consulta o DOM por elementos com o atributo data-observe-resizes e começa a observá-los. A callback — que é invocada inicialmente após a observação e novamente após qualquer alteração — verifica o tamanho de cada elemento e adiciona (ou remove) as classes de breakpoint correspondentes.

Em outras palavras, esse código transformará um elemento de contêiner com 600px de largura assim:

Para:

E essas classes serão atualizadas automática e instantaneamente sempre que o tamanho do contêiner mudar. Com isso, os seletores .SM e .MD corresponderão (mas não os seletores .LG ou .XL) e esse código funcionará perfeitamente.

Customizando breakpoints

O código na callback de ResizeObserver acima define um conjunto padrão de breakpoints, mas também permite que sejam especificados breakpoints personalizados por componente, passando um JSON através do atributo data-breakpoints.

A estratégia recomendada é alterar o código acima para usar qualquer mapeamento-padrão de breakpoints que faça mais sentido para o projeto que se está trabalhando e, em seguida, especificar inline um conjunto de breakpoints específicos para qualquer componente que precise:

O site Responsive Components tem um exemplo de um componente que configura seus próprios breakpoints juntamente com componentes usando breakpoints padrão.

Lidando com alterações dinâmicas no DOM

O exemplo de código acima apenas funciona para elementos de contêiner que já estão no DOM.

Para sites baseados em conteúdo (content-based sites), isso geralmente é bom, mas para sites mais complexos, cujo DOM muda constantemente, será preciso se certificar de que a observação de todos os elementos de contêiner adicionados dinamicamente está acontecendo.

Uma solução “one-size-fits-all” para este problema é expandir o snippet acima para incluir um MutationObserver que acompanha todos os elementos de DOM adicionados. Esta é a abordagem usada no site Responsive Components, que funciona bem para sites de pequeno e médio porte com modificações de DOM limitadas.

Para sites maiores, com atualizações freqüentes no DOM, já se usa algo como Custom Elements ou algum framework com métodos de lifecycle que rastreiam quando elementos são adicionados/removidos do DOM — se for este o caso, provavelmente é melhor apenas fazer um hook a esses mecanismos.

Por exemplo, um elemento personalizado <responsive-container> poderia ser algo assim:

Embora seja tentador criar um novo ResizeObserver para cada elemento de contêiner, é realmente muito melhor criar um único que observa muitos elementos. Para saber mais, veja as descobertas de Aleks Totic sobre o desempenho do ResizeObserver na lista de discussão blink-dev.

Componentes aninhados

Nas primeiras experimentações com esta estratégia, cada componente não foi envolvido com um elemento de contêiner. Em vez disso, foi usado um único elemento de contêiner por área de conteúdo distinta (header, sidebar, footer etc.) e, no CSS, usados combinadores de descendentes (descendant combinators) ao invés de combinadores de filho (child combinators).

Isso resultou em marcação e estilo mais simples, mas rapidamente se desfez quando se tentou aninhar componentes dentro de outros componentes (o que não é muito raro). O problema é que, com a abordagem do combinador descendente, os seletores corresponderam a vários containers ao mesmo tempo…

Após a construção de alguns demos não-triviais, tornou-se claro que uma estrutura direta filho/pai para cada componente e seu contêiner era muito mais fácil de gerenciar e dimensionar. Observe que os recipientes ainda podem conter mais de um componente, desde que cada um deles seja um descendente direto.

Seletores avançados e abordagens alternativas

Como já explicado, a estratégia descrita neste artigo traz uma abordagem aditiva para estilizar componentes: inicia-se com estilos-base para adicionar mais estilos em seguida. Entretanto, esta não é a única abordagem possível. Em algumas situações, pode ser preciso definir estilos que correspondam exclusivamente e somente se apliquem a um breakpoint específico (ex: ao invés de (min-width: 48em), algo como (min-width: 48em) and (max-width: 60em)).

Se fosse este o caso, seria preciso ajustar um pouco o callback de ResizeObserver para aplicar o nome da classe do breakpoint que corresponde atualmente (currently-matching breakpoint). Então, se o componente estivesse em seu tamanho “grande”, ao invés de definir o nome da classe SM MD LG, seria simplesmente LG.

No CSS, seria possível escrever seletores como:

Importante notar que, ao usar a estratégia para correspondência aditiva, ainda pode haver correspondência exclusiva por meio de um seletor como .MD:not(.LG) — embora a leitura desse seletor seja mais custosa (para humanos e máquinas).

No final das contas, é possível escolher qualquer convenção que faça mais sentido para o projeto em questão; que funcione melhor para a situação concreta que se apresente.

O seletor :matches() ainda não é bem suportado nos navegadores atuais. Mas é possível usar ferramentas como postcss-selector-matches e similares para transpilar em algo que funcione de maneira cross-browser.

Breakpoints de altura

Até agora, todos os exemplos focaram em breakpoints de largura. Não é surpresa, já que a maioria esmagadora das implementações de web design responsivo usam a largura e nada mais (pelo menos quando se trata de dimensões da viewport). Contudo, nada na estratégia apresentada no artigo evitaria que um componente respondesse à altura de seu container, já que ResizeObserver reporta ambas as dimensões.

Portanto, se fosse preciso observar mudanças de altura, seria possível definir um conjunto separado de classes de breakpoints — talvez com um prefixo W- para breakpoints de largura e H- para breakpoints de altura.

Suporte dos navegadores

Na data de publicação deste artigo, ResizeObserver só é suportado no Chrome, mas não há absolutamente nenhuma razão para que não seja possível usá-lo imediatamente. A estratégia descrita aqui é intencionalmente projetada para funcionar bem se o navegador não suportar ResizeObserver ou mesmo se o JavaScript estiver desabilitado.

Em qualquer um desses casos, os visitantes verão os estilos-padrão — que devem ser mais do que suficientes para oferecer uma boa experiência. Na verdade, eles provavelmente serão os mesmos estilos que você já está oferecendo hoje.

A abordagem recomendada é usar media queries para o layout do site e, em seguida, essa estratégia de componentes responsivos para componentes específicos que precisem dele (muitos não irão precisar).

Se for preciso fornecer uma UI consistente em todos os navegadores, é possível usar o polyfill de ResizeObserver, que oferece um excelente suporte (IE9+). Entretanto, certifique-se de que o polyfill seja carregado somente quando for realmente preciso.

Também é importante levar em consideração que polyfills tendem a ser mais lentos em dispositivos móveis e, dado que componentes responsivos importam mais em viewports maiores, provavelmente não é preciso carregar o polyfill se o visitante estiver em um dispositivo com viewport pequena.

O site de demonstração Responsive Components leva em conta esta última abordagem: ele carrega o polyfill somente se o navegador não suporta ResizeObserver e se a largura da viewport é pelo menos 48em.

Limitações e melhorias futuras

No geral, a estratégia de componentes responsivos descrita neste artigo é incrivelmente versátil e tem poucas desvantagens. A partir de agora, é altamente recomendado que sites com áreas de conteúdo cujos tamanhos possam mudar independentemente da viewport implementem uma estratégia de componentes responsivos ao invés de confiar somente em media queries (ou alguma solução JavaScript que não aproveita ResizeObserver).

Isto posto, passemos a algumas limitações que valem a pena serem discutidas.

Não é CSS puro

Uma desvantagem óbvia desta solução é que requer mais do que apenas CSS para ser implementada. Além de definir os estilos em CSS, também é preciso se valer de marcação no HTML e coordenar ambos com JavaScript.

Certamente uma solução baseada em CSS puro é a ideal; é o objetivo final. Mas não há motivos sólidos para impedir o uso desta estratégia hoje.

“Flash of un/incorrectly-styled content”

Na maioria dos casos, é uma prática recomendada carregar todo o JavaScript de forma assíncrona, mas, neste caso, o carregamento assíncrono pode levar os componentes a renderizar inicialmente no breakpoint padrão para depois alternar para um breakpoint maior depois de o JavaScript ser carregado.

Embora esta não seja a pior experiência do mundo, é algo que definitivamente não estaria na lista de preocupações em uma solução de CSS puro. E uma vez que esta estratégia envolve coordenação com JavaScript, também é preciso prestar atenção quando estilos e breakpoints são aplicados para evitar esse re-layout.

Uma das maneiras mais ágeis para lidar com isso é incorporar o código de container query no final dos templates de HTML, garantindo que seja executado o mais rápido possível. Em seguida, adicionando-se uma classe ou atributo aos elementos de contêiner uma vez que sejam inicializados e estejam visíveis para que se saiba quando é seguro mostrá-los (e se certificar de considerar o caso em que o JavaScript está desativado ou cause erros quando executado). É possível ver um exemplo disso no site de demonstração.

As unidades são baseadas em pixels

Muitos desenvolvedores de CSS (se não a maioria) preferem definir estilos com base em unidades com mais relevância contextual (por exemplo: emvh etc.), enquanto o ResizeObserver, como a maioria das API de DOM, retorna todos seus valores em px.

No momento, não há realmente nenhuma boa maneira para contornar isso.

No futuro, uma vez que os navegadores implementem CSS Typed OM (uma das novas especificações CSS Houdini), será possível converter fácil e economicamente entre várias unidades de CSS.

Até lá, o custo de realizar esta conversão provavelmente afetaria o desempenho ao ponto de prejudicar a experiência do usuário.

Conclusão sobre Responsive Components

Este artigo descreve uma estratégia para o uso de tecnologias web modernas para criar responsive components: elementos DOM que podem atualizar seu estilo e layout em resposta a mudanças no tamanho de seu contêiner.

Enquanto as tentativas anteriores de construir componentes responsivos eram valiosas em sua exploração/tentativa, limitações na plataforma significavam que essas soluções eram sempre grandes demais, lentas demais ou ambas. Felizmente, agora existem APIs de navegador que permitem construir soluções eficientes e performáticas.

A estratégia descrita neste artigo:

  • Funciona, hoje, em qualquer site
  • É fácil de implementar (copiar > colar)
  • Tem performance tão boa quando uma solução baseada em CSS puro
  • Não requer bibliotecas específicas ou frameworks
  • Vale-se de aprimoramento progressivo (progressive enhancement): quem não tiver as APIs necessárias ou esteja com JavaScript desabilitado ainda consegue usar o site

A estratégia apresentada neste artigo é “pronta para produção” (production-ready), mas ainda estamos muito nos primeiros estágios da coisa.

À medida que a comunidade de desenvolvimento web começar a mudar o design de componentes de viewport ou orientado a dispositivo (device-oriented) para orientado a contêiner (container-oriented), certamente todos veremos o emergir de possibilidades e melhores práticas até então inimagináveis!


Pixels, pixels ou pixels? Dicas de Web Mobile com viewport

Foi-se o tempo em que pixel significava apenas o menor ponto na tela. Bastava dizer que uma imagem tinha 200px, e então ela ocuparia 200 pontos, ou seja, 25% de uma tela de tamanho padrão 800×600.

Mas o mundo mobile mudou completamente o jogo e, hoje, o conceito de pixel pode significar várias coisas.

(Atualização: escrevi mais detalhadamente sobre esses aspectos dos pixels diferentes e viewport, incluindo telas retina, no meu livro A Web Mobile, publicado pela editora Casa do Código. Se você estuda design responsivo, sites mobile, e assuntos relacionados, vai gostar desse livro.)

Os primeiros Smartphones

Era muito comum que os smartphones da Nokia lá pelos idos de 2007 tivessem uma resolução de 240×320 pixels, como um N95.

Quando surgiu o primeiro iPhone, sem teclado e só touch, a Apple decidiu explorar um tamanho maior de tela, 320×480 pixels. Era o dobro dos pixels normalmente usados na época, com um tamanho físico mais ou menos também com o dobro do tamanho.

Esses valores representam o tamanho físico do aparelho, o número de pixels físicos existentes. Na prática, um iPhone conseguia exibir páginas com mais que 320 pixels de largura. O truque era trabalhar com a ideia de zoom.

Na imagem anterior, abrimos o site da Caelum, que tem 960px de largura, em um iPhone de 320px. Repare como, apesar de menor, o Site está sendo renderizado corretamente.

Mas nosso HTML e CSS não foi codificado pensando em 320px, e sim em 960px. Quando colocamos a imagem do logotipo, por exemplo, nosso HTML diz <img src=".." width="160" height="50">. E, obviamente, o logo não está sendo renderizado a 160px, senão ocuparia metade da tela de 320px do iPhone. Se você medir, verá que o logo está sendo renderizado em mais ou menos 52px, ou 1/6 da tela do iPhone.

CSS pixels e o layout viewport

Repare que usamos uma medida de pixels no HTML/CSS que difere do pixel real usado na tela. O navegador do iPhone, na verdade, se comporta como se tivesse 980px de largura, embora o aparelho tenha apenas 320px. Isso é feito para que o usuário possa ver páginas feitas para Desktop sem problemas.

Nossa página funciona como se tivéssemos 980px disponíveis. Quando escrevemos “245px” no CSS, estamos nos referindo a 1/4 dessa tela imaginária de 980px. Na hora de exibir, porém, os 980px serão encaixados nos 320px reais, aplicando um zoom out.

Essa tela imaginária de 980px é o que chamamos de layout viewport. É o tamanho com o qual trabalhamos no nosso HTML/CSS, sem nos preocuparmos com a renderização no aparelho. Repare que um pixel no layout viewport tem outro significado do pixel físico do aparelho. É comum chamá-lo de CSS pixel.

Zoom e o visual viewport

Mas navegar no celular nessa página gigante sem zoom é praticamente impossível. A grande diferença da navegação mobile com a Desktop é o frequente uso do zoom e o scroll em todas as direções.

Na imagem acima, demos um zoom para ver mais detalhes. Repare que a o layout da página continua o mesmo. Um elemento de “245px” continua ocupando 1/4 do total do nosso layout viewport. A diferença é que, agora, só estamos visualizando uma parte do layout viewport; o restante está fora da tela, e precisaríamos fazer scroll para ver.

Isso nos leva para outro conceito importante: o visual viewport, que representa o tanto do layout viewport que conseguimos visualizar no momento.

Geralmente não estamos interessados no tamanho do visual viewport. Lembre que os CSS pixels são sempre relativos ao layout viewport.

Sites mobile e a meta tag viewport

Abrir um site Desktop no celular é uma experiência pouco agradável. Frequentemente, vamos querer criar uma página otimizada para mobile, que não demande tanto zoom e já mostre o conteúdo em tamanho e formato interessantes para uma tela tão pequena.

Como fazer? Obviamente, não podemos deixar a página com layout fixo em, por exemplo, 960px. Podemos tentar um width:100% no elemento principal, pensando em se adaptar a diversos tamanhos de tela.

Nosso layout viewport é considerado como 980px e o site é mostrado como se fosse de Desktop, com zoom mínimo e conteúdo praticamente ilegível. Que tal colocar width:320px, o tamanho real do dispositivo?

O layout viewport continua em 980px mas o conteúdo fica em 320px. O usuário precisa dar zoom para visualizar e, pior, a página fica com um imenso espaço em branco.

O que precisamos é uma forma de redimensionar o layout viewport para que ele seja mais adequado a tela pequena do mobile. A Apple introduziu uma meta tag viewport no iPhone que, depois, foi adotada em praticamente todas as plataformas móveis – Android, Opera, Windows Phone etc.

<meta name="viewport" content="width=320">

Isso indica ao navegador que o layout viewport deve ser 320px. Agora, colocar width:100% vai significar 320px, deixando a visualização mais confortável.

Viewport flexível com device-width

Deixar “320” fixo na nossa tag de viewport pode não ser uma boa ideia. Há diversos aparelhos diferentes no mercado, cada um com tamanho diferente. E mobile agora também inclui tablets, como o iPad, que tem largura de 800px.

É possível deixar a meta tag viewport com tamanho flexível, baseado no tamanho do aparelho. Basta usarmos:

<meta name="viewport" content="width=device-width">

Isso assumirá o valor, por exemplo, de 320px no iPhone e 800px no iPad. Outros aparelhos poderão assumir outros valores.

Altíssimas resoluções

Antes de aparecerem os Androids de alta resolução e, depois, o iPhone 4, toda a história dos pixels se resumia a diferença entre os CSS pixels e os device pixels. Isso porque um device pixel no iPhone clássico significava um pixel físico na tela.

A retina display mudou isso. O iPhone 4 passou a vir com resolução de 640×960 pixels, melhorando a renderização de textos e imagens. Outros celulares foram até além. O Galaxy Nexus, por exemplo, tem resolução HD de 720x1280px.

Como ficam nossas páginas mobile então que assumiam uma resolução bem menor? Com resolução tão alta quanto um Desktop, os celulares mais modernos vão renderizar as páginas bem pequenas, como um site Desktop? Nossas páginas continuam funcionando porque esses dispositivos de alta resolução continuam reportando um device-width de 320px, pra manter a compatibilidade.

A ideia de reportar um device-width diferente do tamanho de pixels físicos surgiu no Android e depois foi copiada pelo iOS e outras plataformas.

Dessa forma, conseguimos evoluir a resolução da tela com densidades de pixels maiores (dpi) sem afetar a forma como o usuário usa nosso Site mobile, que continua otimizado para telas pequenas.

Os três pixels

Um pixel, pode então, representar três conceitos diferentes quando lidamos com mobile:

Pixel físico: número real de pixels na tela. Nos celulares modernos, é um número altíssimo, com ótima resolução, geralmente com densidade acima de 300 dpi.

Device pixel: é o número de pixels reportado pelo aparelho como sendo seu tamanho. É pensado pra ser um valor que ofereça conforto visual para o usuário olhando para aquele tamanho de tela. É comum que esse valor seja 320px em celulares, copiado do iPhone original.

CSS pixel: é o que usamos no HTML/CSS como px, representando um tamanho dentro do layout viewport. Quando colocamos a meta tag viewport com valor width=device-width, estamos dizendo que nosso CSS pixel é igual a um Device pixel.

Hoje, no Desktop, esses três pixels são equivalentes**. Mas, em breve, teremos que lidar com esse tipo de diferença também no Desktop com a chegada das telas de alta densidade também aos computadores.

Lidando com zoom

Mesmo otimizando nossa página para 320px, o usuário ainda pode dar zoom na página. Em alguns cenários, pode ser interessante desabilitar o zoom, o que pode ser feito na tag viewport com user-scalable:

<meta name="viewport" content="width=device-width, user-scalable=no">

De maneira geral, é interessante deixar o usuário dar zoom caso queira, já que este é um gesto comum ao usar a Web no celular. Podemos, porém, controlar os níveis de zoom com as propriedades minimum-scale e maximum-scale:

<meta name="viewport" content="width=device-width, minimum-scale=0.5, maximum-scale=4">

O código acima indica que o usuário pode aumentar até 4x a página e diminuir até pela metade.

Podemos controlar também o nível padrão de zoom quando a página é aberta, com initial-scale:

<meta name="viewport" content="width=device-width, initial-scale=1.0">

O valor 1.0 é muito comum quando trabalhamos com device-width e significa o zoom padrão. Se tivermos uma página Desktop não otimizada pro viewport de mobile, podemos usar essa propriedade para controlar o zoom inicial (lembre que o inicial é mostrar todo o layout viewport de 980px, o que pode não ser interessante).

Por fim, é importante citar um bug do iOS que afeta o zoom e o viewport quando rotacionamos o dispositivo em uma página com width=device-width que permita zoom. Se você abre a página no modo retrato, ele vai assumir o scale como 1.0, deixando o visual viewport igual ao layout viewport. Ao rotacioná-lo para modo paisagem, o dispositivo mantém o visual viewport no valor antigo, mas aumentando o layout viewport. Na prática, a página dá zoom automático e o lado direito da página não fica visível. O usuário, que não deu zoom, precisa diminuir o zoom para ver tudo.

É um bug famoso que acontece só no Mobile Safari do iOS, não existindo no Android e outras plataformas. A solução mais direta é desabilitar o zoom por completo, algo que é feito em diversos sites mobile por causa desse bug. Mas não é a solução ideal, já que poder dar zoom é uma feature que interessa ao usuário mobile. Existem alguns hacks para tentar resolver esse problema no iOS.

Conclusão

Trabalhar com telas diferentes é um grande desafio. O uso da meta tag viewport procura facilitar a padronização das páginas nos mais diversos tamanhos de telas e densidades de pixels. Compreender os diferentes significados de viewports e pixels é essencial para se desenvolver para mobile.

E, usando ainda media queries, podemos criar páginas que se adaptem facilmente a diversos dispositivos.

O curso WD-43 da Caelum, de desenvolvimento Web, trata também de tópicos de Web Mobile. Mostramos o uso do viewport e media queries para criação de uma página responsiva. Além disso, meu livro A Web Mobile, aprofunda em diversos assuntos de design responsivo e aspectos técnicos de sites para dispositivos móveis.

Referências

** No Desktop, quando damos zoom numa página, também temos a complicação dos viewports diferentes e a diferença entre CSS pixels e device pixels. Mas, na prática, todo mundo ignora e assume zoom de 100%, onde os CSS pixels são iguais aos device pixels.


Novo Firefox funciona como um coelho

Novas versões de versões dos navegadores não recebem o zumbido que costumavam obter, mas o Firefox Quantum é uma exceção.

A última versão do navegador da Fundação Mozilla, lançado na terça-feira, é tudo sobre desempenho. O Firefox é duas vezes mais rápido que o ano passado, afirmou a Mozilla. Não é apenas rápido na inicialização – permanece zippy mesmo quando tributado por várias abas.

“Temos um melhor equilíbrio de memória com o desempenho do que todos os outros navegadores”, disse o vice-presidente do Firefox, Product Nick Nguyen.

“Nós usamos 30 por cento menos memória, e o motivo disso é que podemos alocar o número de processos que o Firefox usa em seu computador com base no hardware que você possui”, disse ele à TechNewsWorld.

$ 1 milhão de experiência em US $ 300 para laptop

As melhorias de desempenho em Quantum podem ser uma bebida da fonte da juventude para muitos sistemas de usuários do Firefox. “Um número significativo de nossos usuários estão em máquinas com dois núcleos ou menos, e menos de 4 gigabytes de RAM”, explicou Nguyen.

O aumento de desempenho pode ser atraente para outros usuários também.

“Nós temos um ótimo navegador para você, mesmo que você não tenha o computador mais recente”, disse Nguyen. “Nós vemos uma grande oportunidade para pessoas com US $ 300 laptops ter uma excelente experiência moderna”.

O público-alvo da Quantum provavelmente é proprietário de PCs mais antigos que sentem a maior dor no momento, disse Rob Enderle, analista principal do Grupo Enderle .

“A geração atual de navegadores avançados é bastante intensiva em recursos, o que retarda as máquinas e cria atrasos que os usuários acham realmente irritantes”, disse ele à TechNewsWorld.

Além das melhorias sob o capô, a Mozilla redesenhou a interface do usuário do Firefox.

“Chamamos essa iniciativa” Photon “, e seu objetivo é modernizar e unificar tudo o que chamamos de” Firefox “, enquanto aproveitamos o novo e rápido mecanismo”, escreveu Mark Mayo, vice-presidente sênior do Firefox, em uma publicação online.

“Para criar o Photon, nossa equipe de pesquisa de usuários estudou como as pessoas navegavam na Web”, explicou. “Nós olhamos para o hardware do mundo real para tornar o Firefox ótimo em qualquer exibição, e nós nos certificamos de que o Firefox parece e funciona como o Firefox independentemente do dispositivo que você está usando”.

Momento fortuito?

Além de anunciar o lançamento da Quantum, a Mozilla informou na terça-feira que fez do Google seu provedor de busca padrão nos Estados Unidos e no Canadá.

As receitas dessa parceria devem beneficiar a Mozilla.

“Esperemos que ele ajude a continuar seus esforços de desenvolvimento e construir o motor Quantum”, disse Ross Rubin, analista principal da Reticle Research .

O lançamento de Quantum pela Mozilla foi uma jogada defensiva, ele disse à TechNewsWorld. “É para evitar uma nova erosão da base de usuários do Firefox, que teve um forte sucesso nos últimos anos”.

O Quantum poderia fazer mais por Mozilla do que simplesmente evitar defecções do Firefox, manteve Charles King, analista principal da Pund-IT .

“A Quantum parece ser projetada para trazer usuários anteriores, que abandonaram a Mozilla em última análise para o Google Chrome, de volta ao Firefox”, disse ele à TechNewsWorld.

“A chegada de Quantum também coincide com o que parece um crescente descontentamento entre os usuários do Google Chrome e o Microsoft Edge”, acrescentou King. “Em outras palavras, não poderia haver um tempo melhor para a Mozilla para apresentar um novo navegador inovador”.

Tough Browser Market

Mesmo com vantagens de desempenho, a Quantum terá dificuldade em conquistar o compartilhamento de navegador do líder Chrome, que possuía cerca de 47% do mercado de desktop a partir do mês passado, de acordo com números do NetMarketShare.

Com 6,53 por cento do mercado, o Firefox foi um terceiro distante, por trás do Microsoft Internet Explorer com 12,52 por cento.

“O novo Firefox Quantum é consideravelmente mais rápido, o que foi um grande problema para o antigo Firefox”, disse Greg Sterling, vice-presidente de estratégia e visão da Local Search Association .

“Comparado com o Chrome, o antigo Firefox era muito lento, então esta é uma melhoria real”, disse ele à TechNewsWorld.

“O desafio será conquistar os usuários que desertaram para o Chrome – além dos que são filosóficamente opostos ao Google”, afirmou Sterling. “Eu suspeito que veremos uma melhoria incremental no compartilhamento de mercado do Firefox, mas esse lançamento não mudará as coisas drasticamente”.


10 fatos fascinantes sobre a World Wide Web em seu 25º aniversário

“Vá descobrir o que é essa coisa da World Wide Web”. Ironicamente, essa foi a minha primeira tarefa de jornal. Ainda estou tentando desvendar os infinitos complexos de tunelamento da Web todos esses anos mais tarde, mesmo hoje no seu 25º aniversário. É o que eu faço por um trabalho, o que um jornalista de impressão da velha escola como eu pode nem ter se não for a web.

A ideia do que se tornaria a World Wide Web foi proposta há 25 anos hoje em um computador NeXT , em 12 de março de 1989. Esse segmento de texto sem graça e sem imagem é o que a primeira página de destino da web parecia. Não era mais do que um fundo branco com palavras negras e um pouco de links “hipermídia” azuis para clicar. Nenhum Google. Não há Twitter. Não há Facebook. Eles ainda estavam a alguns anos de distância.

Havia, no entanto, todos os 17 “assuntos” para ler, juntamente com as perguntas internas de cinco perguntas da Web , escritas por ninguém menos que o físico Tim Berners-Lee , o homem que conceituou a ferramenta revolucionária de ligação e compartilhamento de informações em um escritório do CERN na Suíça. (CERN é abreviação da Organização Europeia de Pesquisa Nuclear).

A rede recém-nascida não era exatamente fascinante, mas foi um começo. O nascimento de uma fascinante força cultural intangível que amadureceu em uma massa virtual agitada de cerca de 4,1 bilhões de páginas , com inúmeras mais vendo online agora quando você lê isso.

É um eufemismo dizer que a web mudou para sempre a maneira como vivemos, trabalhamos, jogamos e nos comunicamos, para o pior e o pior. Eu me inclino para melhor.

Então pegue uma fatia de bolo, envie um cartão de aniversário de rede social # web25 hashtagged e confira esses 10 fatos históricos legais sobre a web no seu 25º aniversário:

1. O Pai da web quer que você lute por sua liberdade. Berners-Lee, de 58 anos, está comemorando o aniversário histórico de seu protocolo pioneiro de comunicação colaborativa hoje implorando seus usuários a “defender seus princípios fundamentais” de liberdade, não censura e neutralidade da rede.

O vocalista de Edward Snowden está pedindo que as pessoas apoiem uma “Declaração de Direitos dos Usuários de Internet” universal. A iniciativa ” Web We Want ” pretende estabelecer proteções de usuários pessoais, incluindo muitos agora rotineiramente pisoteados pela NSA. O projeto também pretende expandir a web para os dois terços do mundo que ainda não tem acesso a ela.

Relacionado: Isto é o que a Internet parecerá em 2025

2. O primeiro site da Internet foi on-line em 6 de agosto de 1991. Berners-Lee e seus colegas membros da equipe do CERN lançaram http://info.cern.ch com uma página de destino que só continha 153 palavras. Definiu a World Wide Web (“W3”) como “uma iniciativa de recuperação de informações hipermídia de ampla área com o objetivo de dar acesso universal a um grande universo de documentos” e continha 25 links para informações adicionais básicas sobre a iniciativa pioneira.

3. Deixe a liberdade soar. Em 30 de abril de 1993, o CERN anunciou que sua tecnologia da World Wide Web estará disponível para todos gratuitamente. A declaração pública declarou que os principais componentes da estrutura da web permaneceriam no domínio público, dando a qualquer um no mundo liberdade para usá-los. “O CERN renuncia a todos os direitos de propriedade intelectual deste código, fonte e binário, e a permissão é dada a qualquer pessoa para usar, duplicar, modificá-lo e distribuí-lo”, lê a declaração histórica.

4. Agora você pode navegar livremente pela Internet. Archie, que é amplamente considerado o primeiro motor de busca primitivo, foi ao vivo em 1990. Mas uma série de outros seguiram o exemplo na década seguinte, incluindo gigantes de rastreamento da web que ainda são fortes hoje como Yahoo, MSN e, sim, o poderoso Google.

5. Os bibliotecários também surfam. Temos um bibliotecário de Nova York que se chama Net-mom® para agradecer o termo “Navegar na Internet”. Jean Armour Polly escreveu um artigo chamado “Surfing INTERNET” que foi publicado em um boletim da biblioteca da Universidade de Minnesota em 1992. Alguns creditar Mark McCahill , o programador por trás de uma alternativa inicial da web chamada protocolo Gopher, por ter resistido a frase.

6. Uma banda de garotas é a primeira imagem publicada on-line. Berners-Lee também possui os direitos de se vangloriar para outro impressionante primeiro: carregar a primeira foto para a web em 1992. Foi uma imagem quebrou nos bastidores de uma banda de rock com temas de física de todas as meninas chamada Les Horribles Cernettes , fundada em 1990 por um designer gráfico no CERN. Berners-Lee examinou a foto, o upload para um Mac e FTPD-lo para o agora famoso info.cern.ch . A web que Berners-Lee inventou viveu, mas as Cernettes terminaram em 2012. Bummer.

7. Os navegadores primitivos ajudaram a web a atingir uma massa crítica. O NCSA Mosaic, o primeiro navegador gráfico amplamente utilizado na web é muitas vezes creditado com a internet para fora da obscuridade geeky. Marc Andreessen e Eric Bina desenvolveram o icônico navegador preto, cinza e azul no Centro Nacional de Aplicações de Supercomputação da Universidade de Illinois em 1993. Antes do Mosaic, os usuários da web tiveram que se preocupar com interfaces caras e complicadas, como Lynx.

O Netscape Navigator, que aterrissou na internet um ano depois, no dia 15 de dezembro de 1994, também desempenhou um papel importante na disponibilização da web ao público em geral. (Lembre-se da primeira atribuição de jornal que marquei? Peguei a pesquisa do meu artigo através de um vórtex Netscape sem fundo e frustrantemente lento por três horas estranhas. Bom tempo.)

Mosaico pode levar o título para o primeiro navegador web popular, mas a honra do navegador gráfico inaugural pertence a ViolaWWW . O complexo “navegador hipermídia”, que só funcionou nas estações de trabalho X Windows System e Unix, lançado em 9 de março de 1992.

8. A internet não é a web e a internet não é a internet. Não os faça torcer como a maioria das pessoas , especialmente não se você estiver no Silicon Valley. A Internet era uma coisa muito antes da web e a web não existiria sem a internet. A internet, cujas raízes podem ser rastreadas até a invenção do modem em 1958, é uma enorme infra-estrutura que combina milhões de computadores em todo o mundo. A World Wide Web é um vasto sistema de documentos de hipertexto interligados acessados ​​na internet.

9. Bilhões de pessoas navegam na web. Dos 7,1 bilhões de pessoas do mundo, cerca de 2,4 bilhões de pessoas estão online hoje. Isso é 37,7 por cento da população total do mundo. Cerca de seis de sete pessoas em todo o mundo têm acesso à internet. Aproximadamente 70 por cento dos internautas navegam na internet todos os dias.

10. Os americanos balançam a web mais. Os usuários dos EUA representam 78,6 por cento do uso global da internet, seguidos pela Austrália (67,6 por cento), pela Europa (63,2 por cento), América Latina / Caribe (42,9 por cento), Oriente Médio (40,2 por cento), Ásia (25,7 por cento) e África (15.6). Surpreendentemente, cerca de 24 nações permanecem completamente offline.


5 Dicas para contratar um ótimo desenvolvedor da Web

Um desenvolvedor web pode ser uma das suas contratações mais críticas. Afinal, essa é a pessoa que criará o rosto online da sua empresa e permitirá que você interaja virtualmente com seus clientes.

Então, é especialmente importante que você contrata o talento certo pela primeira vez. Caso contrário, corre o risco de prejudicar o seu negócio, bem como perder tempo e dinheiro buscando uma substituição.

Aqui estão cinco dicas que podem ajudar no processo de seleção:

1. Contrate primeiro o DNA, depois a experiência de trabalho. 
Quando eu contrato desenvolvedores web, seu DNA pessoal é a consideração mais importante. Embora a experiência seja importante, o maior preditor de sucesso é o DNA inato de alguém e como ele se adapta à sua empresa. São movimentação, determinação, persistência, curiosidade, importante para você cultura? Ou, você é mais discreto e relaxado sobre gerenciamento de tempo e prazos? Quaisquer que sejam as características que compõem a sua cultura, você deseja garantir que o desenvolvedor web se encaixe.

Por exemplo, um desenvolvedor web brilhante que trabalhou em uma grande instituição financeira pode não funcionar bem em uma inicialização. Por quê? Uma inicialização geralmente requer características como a versatilidade, a adaptabilidade, a tomada de riscos e uma personalidade auto-iniciante, mas estas podem ser menos importantes em uma grande empresa.

Então, faça uma lista dos requisitos de DNA da sua empresa. Você promove um ambiente de movimentação implacável? Você quer grandes jogadores de equipe? Se você encontrar cinco requisitos, verifique se o entrevistado coincide com pelo menos três. A contratação de DNA também pode ajudá-lo a começar a definir uma cultura de empresa e garantir que sua equipe funcione bem em conjunto.

Claro, é fácil para algumas pessoas fingir em uma entrevista, então você pode precisar avaliá-los de outras maneiras para garantir que eles são um bom ajuste.

2. Experimente um novo desenvolvedor com um pequeno projeto primeiro. 
Embora você possa pensar que você identificou seu candidato ideal, apenas para ter certeza de que ele deveria dar a ele um projeto pequeno e não crítico. Isso pode deixar você observar a pessoa em ação e fornecer informações adicionais além da entrevista de emprego.

Você pode ver o quão eficiente é o candidato na entrega de produtos e como o produto final é buggy. Ele ou ela foi além e além para obter o produto entregue? Quão criativa foi a solução? Quão bem ele ou ela trabalhou em uma equipe e comunicar problemas e atrasos?

3. Escolha um desenvolvedor com aptitude, e não um conjunto de habilidades específico. 
No espaço tecnológico, as habilidades tornam-se obsoletas a cada dois anos, dar ou receber. Então, é melhor contratar um desenvolvedor web que possa aprender novas tecnologias facilmente em vez de alguém que conheça uma tecnologia específica agora, mas não pode se adaptar quando uma nova vem.

A maneira mais fácil de detectar se alguém se adapta bem à mudança é fazer perguntas que revelem se um desenvolvedor da Web tem um amor por aprender. Por exemplo:

  • Quais as novas linguagens de programação que você aprendeu recentemente?
  • Quais são os seus locais de acesso para aprender novas dicas e truques de tecnologia?
  • Quais são suas conferências de tecnologia favoritas?

4. Não faça perguntas triviais sobre programação. 
Estes são exemplos de questões triviais que você deseja evitar quando entrevista os desenvolvedores web:

  • Quem é o principal criador da linguagem de programação Java?
  • Em que ano o PHP foi lançado?
  • Qual é a origem do nome do idioma do script Python?

Embora tal informação possa parecer útil, as questões triviais são muitas vezes uma maneira terrível de determinar se alguém é inteligente. Eles simplesmente destacam pessoas que podem memorizar as coisas.

Como regra geral, quando realizo entrevistas técnicas, nunca faço perguntas que possam ser facilmente pesquisadas e encontradas on-line. Em vez disso, eu me concentro em perguntas abertas e escuto. O que eu procuro é a quantidade de candidatos de paixão que mostram em suas respostas e como eles se comunicam e explicam os termos técnicos.

Alguns exemplos de perguntas abertas:

  • Como você gerencia conflitos em um aplicativo da Web quando diferentes pessoas estão editando os mesmos dados?
  • Quais padrões de design você usou e em que situações?
  • Você pode nomear quaisquer diferenças entre design orientado a objetos e design baseado em componentes?

5. Contratação lenta, fogo rápido. 
Tome seu tempo de contratação, mas se você perceber que a pessoa não está trabalhando, deixe-o ir tão rápido quanto você puder. Um desenvolvedor web ineficaz pode ser perturbador para toda a equipe e potencialmente o projeto inteiro.

No Webgrrls.com, cometi um importante erro de contratação há alguns anos e deixei essa pessoa continuar por muito tempo. Embora ele fosse um desenvolvedor principal talentoso, ele às vezes desapareceu por dias, faltando prazos importantes. Os prazos em falta podem ser especialmente prejudiciais para as startups, onde os recursos são apertados e a capacidade de desenvolver e melhorar produtos de forma rápida e eficiente pode fazê-los ou quebrá-los.

A regra do fogo rápido pode ser difícil de seguir em pequenas empresas onde muitas vezes há um sentimento de que todos estão juntos e formando amizades íntimas. Mas não permita que isso o pare.