Builds Customizáveis

O jQuery funciona como uma biblioteca real. Você pode escolher quais livros entram e quais vão embora da sua prateleira pessoal. Desde a compilação 1.8 já existia a opção de personalizar a biblioteca. Agora na versão 2.0 este recurso foi ampliado. É possível selecionar entre 12 módulos diferentes.

• ajax: Todas as funcionalidades do AJAX: $.ajax(), $.get(), $.post(), $.ajaxSetup(), .load(), transports, e todos os atalhos de ajax, como.ajaxStart().
• ajax/xhr: Apenas o evento de transporte do AJAX XMLHTTPRequest.
• ajax/script: Método de transporte AJAX// <![CDATA[; usado para recuperar scripts.
• ajax/jsonp: Método de transporte JSONP AJAX; depende do transporte ajax/script.
• css: O método .css() mais .show(), .hide() e .toggle() não animados.
• deprecated: Métodos documentados como obsoletos mas que não foram removidos. Atualmente apenas .andSelf().
• dimensions: Os metodos .width() e .height() , incluindo as variações inner- e outer-.
• effects: O método .animate() e seus atalhos como .slideUp() e .hide("slow").
• event-alias: Eventos com gatilhos, como .click() ou .mouseover().
• offset: Os métodos .offset(), .position(), .offsetParent(), .scrollLeft(), e .scrollTop()
• wrap: Métodos .wrap(), .wrapAll(), .wrapInner(), e .unwrap().
• sizzle: O motor de seletor Sizzle. Quando este módulo é excluido, ele é substituido por um motor de seletor rudimentar baseado no método querySelectorAll do browser, que não é suportado pelas extensões de seletores ou pela semântica aumentada do jQuery.

Eliminar os módulos inúteis para o seu projeto é uma boa prática que pode pode diminuir e muito o tamanho da biblioteca (a versão mais simples pode chegar a cerca de 10Kb quando minificada). Mas Infelizmente ainda não é uma solução prática já que para construir sua versão customizada do jQuery você precisa conhecer um pouco sobre Git, Node.js e Grunt. Você pode ler as instruções completas no repositório da equipe. Ou você pode usar o gerador automático jQuery builder. Ele ainda não é compatível com todos os módulos novos, mas já quebra um galho. Ah, e ele funciona também para personalizar as versões mais antigas do jQuery.

Parece óbvio, mas vale lembrar que os plugins que você pretende utilizar precisam estar trabalhando com os mesmos módulos que você escolheu ou simplesmente não vão funcionar.

O jQuery 2.0 não é compatível com IE 6/7/8

É isto mesmo. Segundo a equipe de desenvolvimento o jQuery é "feito para a Web moderna" e ao abandonar o suporte aos browsers mais antigos eles podem agora se concentrar em deixar a biblioteca mais rápida, leve, etc. Esta atitude foi no mínimo controversa já que muitos profissionais optavam por desenvolver em jQuery em detrimento de soluções mais práticas como HTML5/CSS3 justamente pela retro-compatibilidade.

Se desenvolver algo acessível para as versões mais antigas do Internet Explorer é algo realmente importante pra você não se desespere. A versão 1.9 continuará sendo suportada pela equipe... Ou seja, a partir de agora existirão dois caminhos de desenvolvimento diferentes. Algo como duas timelines: uma para a versão 1x e outra para a 2x. Mas é provável que as próximas mudanças da família 1x sejam apenas correções de bugs. Para ser sincera não acredito que implantarão recursos novos. Espero estar errada.

Mais Leve

O jQuery 2.0 é 12% mais leve do que a versão anterior (1.9.1). Mas isto, infelizmente, não foi graças a uma otimização mágica. Ser mais leve frequentemente implica em perda de funcionalidades e esta foi a decisão estratégica da equipe do jQuery. Estes 12% a mais eram justamente os patches de compatibilidade do IE que foram retirados. E podemos esperar mais cortes deste tipo no futuro. Provavelmente as próximas atualizações do jQuery não serão compatíveis com versões antigas do Android/Webkit 2.x.

Onde eu consigo

http://code.jquery.com/jquery-2.0.0.min.js (minificada, para produção)
http://code.jquery.com/jquery-2.0.0.js (não minificada, para teste)

Fallback

Como dito anteriormente o jQuery 2.0 não é compatível com IE 6/7/8. A solução proposta pela equipe é utilizar comentários condicionais como Fallback.

<!--[if lt IE 9]>
<script src=”jquery-1.9.1.js”></script>
<![endif]–>
<!–[if gte IE 9]><!–>
<script src=”jquery-2.0.js”></script>
<!–<![endif]–>

Vale a pena mudar?

A resposta para esta, como muitas outras perguntas sobre desenvolvimento web é depende. Eu também gostaria de viver em um mundo mágico onde ninguém utiliza IE8, mas infelizmente ele ainda é um browser relativamente popular. Os números flutuam de acordo com as pesquisas que você utiliza, mas considerando a W3C Schools o IE 8 representa cerca de 5.3% dos usuários. Se você esta pensando em implementar o jQuery 2.0 no seu site minha recomendação é ignorar estatísticas genéricas e analisar o seus próprios dados para conhecer seus visitantes e tomar uma decisão informada. No geral a nova versão tem mais prós do que contra e até que a participação de mercado do Internet Explorer 6. 7 e 8 realmente diminua ela pode ser inviável se este for seu público alvo. Manter duas versões em comentários condicionais, como sugerido pela própria equipe do jQuery, pode ir contra a proposta de facilitar o desenvolvimento e acabar mais atrapalhando que auxiliando, já que precisaríamos trabalhar com duas bibliotecas diferentes. Se compatibilidade com o IE não é um problema vá em frente e seja feliz!

Pouco demais, tarde demais?

Quando o jQuery foi lançado ele representou uma mudança grande no modo como pensávamos a internet. Naqueles idos tempos de 2006 a web era um lugar bem diferente. O iPhone ainda não havia sido lançado e nem se sonhava em algo como design responsivo. Muitos sites naquela época ainda utilizavam o formato Flash para interações, mas isto já estava com os dias contados. A nova ordem agora era cortar o peso desnecessário e desenvolver sites mais semânticos e compatíveis com multiplos browsers. Mas alguns desenvolvedores se sentiram orfãos da capacidade de animações dinâmicas oferecidas pelo Flash. O jQuery chegou na hora certa para suprir esta necessidade ao mesmo tempo que oferecer uma solução crossbrowser. Muita gente se jogou de cabeça e centenas de plugins surgiram para todo tipo de situação. Slider, carrosel, shadowbox, pequenas animações... O mecanismo dos plugins era tão simples que até quem não era familiarizado com JavaScript conseguia implementar com facilidade. E isto foi utilizado com um certo exagero. O que era novo acabou tornando-se repetitivo e até desnecessário algumas vezes. Por uma ironia do destino, o jQuery aos poucos vai sofrendo o mesmo destino do Flash: ser pesado demais para a nova geração. Com o crescimento de dispositivos móveis a preocupação com a perda de peso no browser ficou ainda maior. E as tendências de design minimalista acabam jogando para escanteio todas aquelas firulas e animações desnecessárias. O que entusiasmava muitos no inicio acaba sendo ouvido com uma certa torcida de nariz da comunidade de desenvolvedores.

O HTML5 e o CSS3 ganharam mais espaço (afinal você pode criar diversos elementos da user interface utilizando apenas estas tecnologias) e houve uma revitalização do JS baunilha. É, de repente, o jQuery não parece mais tão leve e legal assim quanto no inicio. É claro, ainda existe muita coisa bacana para ser feita com jQuery, mas infelizmente não existe a mesma empolgação de quando era algo novo. Agora é esperar para ver se as próximas versões irão revolucionar novamente a vida dos desenvolvedores.

Saiba mais

jQuery 2.0 Release

O post jQuery 2.0 foi originalmente publicado em Tableless.

Fico apenas chateado por não ter feito anotações das palestras. Eu adoro fazer isso como você pode ver aqui e aqui. Como eu estava organizando e correndo muito no dia, sem chance de sentar e prestar atenção 100% do tempo em todas as palestras. A nossa sorte é que o pessoal da Caravana Web estava lá e anotou tudo, veja na íntegra no blog da Eventick!

Se você não foi, fique com um fiozinho do que aconteceu vendo as fotos, palestras e o vídeo do Brad Frost:

Brad Frost

Fotos do evento

Bernard de Luna

Pra ver a apresentação do Bernard, clique aqui.

Clauber Stipkovic

Para ver a apresentação do Clauber, clique aqui

Edu Agni

Rene de Paula Jr

Fellyph Cintra

O post Tableless Conference #2 2013 foi originalmente publicado em Tableless.

Diante disso, é cada vez mais importante que cada detalhe de um e-commerce ou uma landing page seja pensado para atrair mais leads, ou seja, mais conversões. Por isso, a otimização de conversão em sites tem se mostrado cada vez mais presente no setor de marketing digital e SEO e fazer uso dessas técnicas com certeza irá aumentar o número de leads e consequentemente o aumento da sua receita.

As técnicas de otimização de conversão também têm se mostrado presentes, em especial às landing pages, isto é, páginas de destino onde o usuário possa concluir uma meta ou objetivo final do site: Conversão. As landing pages são criadas exatamente para fazer com que o usuário encontre facilmente o que deseja e possa sair da página satisfeito e com seu objetivo concluído. Neste artigo, irei citar 07 dicas importantes de otimização de conversão que lhe auxiliarão a melhorar os resultados de qualquer landing page. Vamos a elas:

1 – Call to Actions claros

O Call to Action, ou chamada à ação, são botões de conversão. É clicando nos botões de Call to Action que o usuário é levado para a conversão de uma landing page. Ele é o botão mais importante da página e por isso, é fundamental que ele seja extremamente claro e objetivo em sua chamada e que preferencialmente possua uma cor que contraste com o restante das cores do site e que chame mais atenção que os outros elementos.

Neste exemplo, o Call to Action é fácil de ser visto na página. O botão se encontra no topo da página e não precisamos usar a barra de rolagem para visualizá-lo. A chamada “Crie uma conta grátis” está mais do que clara e o botão é amarelo, constrastando com o resto das cores. Tenha um botão de Call to Action onde todos possam ver sem ter que pensarem.

2 – Quanto menos escolhas melhor

Landing pages: páginas de destino onde o usuário possa concluir uma meta ou objetivo final do site.

Muitas landing pages são projetadas para terem bastante conteúdo, fazendo com que o usuário tenha o máximo de informação relevante possível, afinal, você sabe o quanto seu produto ou serviço é maravilhoso e quanto mais informação sua página oferecer, mais você convencerá seus visitantes de que realmente é bom. A verdade é que a coisa toda não funciona assim.

Quando estamos visitando a página pela primeira vez, damos uma olhada por cima e em questão de milésimo de segundos, tomamos decisões e clicamos onde achamos que seja o lugar certo. A questão é que quanto mais informações e distrações sua página conter, mais o usuário ficará confuso e poderá simplesmente sair da sua página. Faça com que sua landing page contenha informações precisas e que seu visitante possa ter a menor possibilidade de escolha possível.

3 – Formulários chatos

Quem aqui gosta de preencher um bom e velho formulário de contato? Imagine você entrando em uma loja de sapatos onde o vendedor insiste em solicitar o seu nome, e-mail, idade, data de nascimento, número do cartão de crédito, endereço, escolaridade, RG, CPF, carteira de motorista, nome da mãe, nome do pai, nome dos irmãos, nome do papagaio e uma série de informações? Você só quer comprar um sapato e ir embora, mas se não preencher esses dados não levará. Isso é bastante parecido com o que acontece nos formulários de landing pages.

É comum vermos páginas nos oferecendo um simples e-book grátis, mas para isso precisamos preencher dezenas de campos chatos de formulário. Ninguém gosta de formulários. Nem mesmo o mais curtos. Se sua landing page realmente precisa de um formulário para fazer a captação de leads, procure deixá-lo simples e com os campos mais básicos como nome, e-mail e mensagem. Facilite a vida dos seus visitantes.

4 – Textos muito extensos

Se é uma coisa que aprendi em usabilidade, essa coisa é: Os textos servem para não serem lidos. Quantas vezes nos deparamos com páginas usando aqueles textos institucionais, chatos e enfadonhos, mas que na verdade sabemos que não quer dizer muita coisa e que não fariam falta se não estivessem ali?

Exceto em casos de blogs ou páginas que precisem de artigos, uma landing page não deve conter textos muito extensos. Isso deixará sua página chata e poderá entendiar o usuário. A verdade é que realmente não lemos os textos, mas damos uma leve “passada de olho” neles. Fazemos isso muito devido a falta de tempo, criando o hábito de mal ler os textos de uma revista ou jornal, mas sim identificar apenas o que for interessante para nós e acabamos ficando bons nisso.

Por isso, procure deixar os textos da sua landing page curtos e diretos. Uma boa dica que aprendi com Steve Krug, no livro “Não me Faça Pensar” é cortar pela metade o texto que você escreveu para sua landing page. A partir daí, você corta outra metade do texto e talvez assim você tenha um texto mais direto. Tenho certeza que muitas frases não farão a menor falta porque não eram importante. Deixe os títulos mais importantes em destaques e subtítulos em menor destaque e faça com que os textos realmente estejam lá por ser uma informação importante. Faça com que eles façam total sentido na página de forma fácil, objetiva e direta.

5 – Design sem distrações visuais

O design de uma landing page não deve existir apenas para deixar a página “bonita”. Ele existe para causar impacto e ajudar a sua marca a transmitir uma sensação positiva nos visitantes de seu site. Tendo isso em vista, o design da página deve ser conciso e objetivo. Quanto mais houver elementos que possam distrair o visitante, mais o lead irá se afastar e não concluir sua meta. Procure fazer com que o layout da sua landing page seja condizente com os elementos de imagem e vídeo. Crie uma unidade visual orientando o usuário a fazer o caminho da sua conversão e não deixe que nada atrapalhe esse caminho.

6 – Evite slides animados

Sabemos que os slides animados no topo de uma landing page podem deixar o funcionamento e transmissão do conteúdo das informações mais dinâmico. Bem, em alguns casos sim, mas na maioria dos casos, ou seja, em landing pages otimizadas para conversão eles podem atrapalhar a navegação do usuário e distraí-los da conversão. Sua landing page não precisa ser um parque de diversões e também não precisa estar na última moda da tecnologia. Ele precisa converter e para isso deve ser o mais enxuto possível. Não se preocupe com a simplicidade da sua página, é exatamente isso o que estamos procurando fazer: páginas extremamente simples de serem navegadas para que os usuários convertam sem dificuldades. Isso é otimizar conversão. Slides podem ser bonitos de ver, mas talvez isso te atrapalhe.

7 – Títulos claros e objetivo

Os títulos da sua landing page devem ser extremamente claros e objetivos. Procure escrevê-los usando sua principal palavra-chave e indicando ao usuário claramente do que se trata. Lembre-se que geralmente os seus visitantes podem chegar na sua landing page através do Google, seja busca orgânica ou paga, e por isso buscaram por determinada palavra-chave. Se o usuário buscou por “Smart TV 42 polegadas”, é fundamental que sua landing page trate apenas disso e que possua títulos chamativos sobre este assunto.s

Conclusão

As técnicas de otimização de conversão obviamente não se resumem apenas em 7 dicas. Essas são consideradas as mais importantes e cada projeto possuem suas próprias estratégias e características. Mas a prática dessas otimizações resultam em aumento de conversão, o que em casos de e-commerce é aumento de receita. Estude e pratique otimização de conversão em suas landing pages. Como SEO, as técnicas não se restringem em receitas prontas, mas sim estratégias personalizadas para cada objetivo, seja uma venda de um produto ou geração de um lead através de um formulário.

O post 7 dicas de otimização de conversão em landing pages foi originalmente publicado em Tableless.

Firefox OS é novo sistema operacional móvel desenvolvido pela Mozilla. Para nós desenvolvedores web ficou fácil criar aplicativos para aparelhos mobile, pois para desenvolver é utilizado apenas HTM5, CSS e JAVASCRIPT.

Para testar seus aplicativos não precisa ter um smartphone com Firefox OS, basta baixar a extensão (Firefox OS Simulator) do Firefox disponível em Windows, Linux e MAC OS X.

Colocando em pratica

Primeiro passo é instalar a extensão Firefox OS Simulator em seu Firefox.

Firefox OS Simulator – links para Download

• Windows – download
• Linux – download
• Mac OS X – download

Iniciando Firefox OS Simulator

Para abrir o Firefox OS Simulator procure a aba Ferramentas > Desenvolvedor web > Firefox OS Simulator. Uma aba será aberta com as informações do Firefox OS Simulator. Nesta aba você pode desligar e ligar o emulador e nela também são adicionados os aplicativos que serão instalados no emulador assim que iniciado. Para adicionar seus aplicativos, clique em Add diretory e localizar a pasta em que você desenvolveu seu aplicativo.

Criando uma aplicação para Firefox OS

Para iniciar, crie uma pasta do seu projeto e nela ficarão os arquivos da sua aplicação. No meu caso willemallan. Dentro do diretório crie um arquivo manifest.webapp este arquivo contém as configurações do projeto como: nome, autor, versão, icones e outros dados importantes do aplicativo. Veja abaixo o exemplo do arquivo manifest.webapp.

{
    "version": "0.1",
    "name": "Willem Allan",
    "description": "Willem Allan - Blog posts",
    "launch_path": "/index.html",
    "icons": {
        "16": "/imgs/icons/wi16.png",
        "48": "/imgs/icons/wi48.png",
        "128": "/imgs/icons/wi128.png"
    },
    "developer": {
        "name": "Willem Allan",
        "url": "http://willemallan.com.br"
    },
    "installs_allowed_from": ["*"],
    "locales": {
        "es": {
            "description": "Willem Allan - Blog posts",
            "developer": {
                "url": "http://willemallan.com.br"
            }
        },
        "it": {
            "description": "Willem Allan - Blog posts",
            "developer": {
                "url": "http://willemallan.com.br"
            }
        }
    },
    "default_locale": "en"
}

Analisando o código acima, perceba que possuem locais para definir a versão do aplicativo, nome e descrição. Logo após, repare que o launch_path aponta para /index.html, que é o primeiro arquivo a ser carregado quando o aplicativo for iniciado. Pode ser também definido os ícones em diversos tamanhos. Por último temos opções para os dados do desenvolvedor que também podem ser traduzidos em outros idiomas.

Mão na massa

Para iniciar crie um diretório da sua aplicação e em seguida crie um arquivo index.html e utilize o arquivo citado acima manifest.webapp alterando as configurações do seu projeto.

O resultado final é uma pasta com o nome do projeto e dentro os arquivos index.html e manifest.webapp.

Adicione um texto qualquer no arquivo index.html, pode ser o famoso hello world.

<html>
<head>
    <title>Primeira aplicação Firefox OS</title>
</head>
<body>
    <h1>hello world!!! Primeira aplicação Firefox OS</h1>
</body>
</html>

Para testar a aplicação é preciso ir na extensão do Firefox OS Simulator, Bashboard e adicionar a pasta do projeto “add directory”, depois inicie o emulador a aplicação será instalada e aparecerá nos aplicativos.

• github – exemplo de aplicação do Firefox OS: link
• github page – link

Saiba mais

• Firefox OS Quick Start – link
• Desenvolva para Firefox OS sem um smartphone – link
• Aplicativos de exemplo – link
• Disponibilizando um aplicativo no Mozilla Marketplace – link

O post Desenvolvendo para Firefox OS foi originalmente publicado em Tableless.

Colocamos ali informações básicas, simples, para quem está entrando agora na área. Novato mesmo. Como eu disse, é um rascunho e vai virar site depois para contemplar mais conteúdo.

Se você quiser ajudar, ele está no GitHub.

O post Para Iniciantes foi originalmente publicado em Tableless.

É impossível prever com exatidão quais propostas vieram para ficar e quais vão se perder no limbo dos browsers, mas vale a pena ficar de olho nestas aqui…

Imagens responsivas

Picture

Esta proposta pode tornar realidade um sonho de muitos desenvolvedores: imagens responsivas. Esqueça soluções server side complexas ou javascripts pesados. Utilizando você pode servir imagens em diferentes resoluções e / ou densidade de pixels diretamente no HTML. E o melhor, através de Media Queries apenas a imagem correta para cada situação é baixada pelo navegador!

As possibilidades de uso são imensas. É possível utilizar imagens adequadas para cada ponto de quebra do layout em diferentes dispositivos, servir imagens coloridas ou em preto e branco de acordo com a capacidade da tela ou até mesmo mostrar imagens diferentes de acordo com a orientação do dispositivo (retrato ou paisagem).

Na prática a tag picture poderia ser aplicada da seguinte maneira:

<picture>
  <source media="(min-width: 40em)" srcset="fotogrande.jpg 1x, fotogrande-hd.jpg 2x">
  <source srcset="fotopequena.jpg 1x, fotopequena-hd.jpg 2x">
  <img src="fotofallback.jpg" alt="">
</picture>

Em dispositivos cuja largura minima é maior do que 40 EM o arquivo “fotogrande.jpg” seria exibido, enquanto para larguras menores o arquivo “fotopequena.jpg” seria o escolhido. Os atributos “1x” e “2x” referem-se a densidade de pixels. Ou seja, versões em HD seriam servidas para monitores de alta resolução como o retina display. No caso de não compatibilidade do atributo com o browser uma normal serviria como fallback.

Infelizmente, por enquanto, nenhum browser suporta o atributo. Mas isto deve mudar em breve. Pelo menos no que depender do Responsive Images Community, o grupo de desenvolvedores empenhado em discutir, refinar e divulgar o atributo. Eles até construíram um novo build do Chromium só para demonstrar como tudo funcionaria ao vivo. Já existe um rascunho não-oficial do projeto para a W3C com a documentação completa. Na página do grupo no Github também é possível acompanhar as discussões.

Srcset

Existe ainda uma proposta diferente apoiada pelo mesmo grupo. Incrementar o bom e velho img através do atributo srcset.

<img src="fallback.jpg" alt="" srcset="fotopequena.jpg 640w 1x, fotopequena-hd.jpg 640w 2x, fotogrande.jpg 1x, fotogrande-hd.jpg 2x ">

Esta sintaxe é mais concisa e já existe como um rascunho oficial na W3C. O conceito ainda está em um estágio bem inicial de desenvolvimento, mas de qualquer forma esta é uma discussão que vale a pena ser acompanhada.

Rel=”logo”

Buscar por logotipos na internet pode ser uma tarefa difícil. Serviços como Google imagens acabam retornando arquivos de baixa qualidade, rasterizados e pequenos demais. Alguns sites como Brands of the World tentam fazer um apanhado geral de alguns logotipos, mas acabam não dando conta do trabalho. Sem contar que é impossível garantir que o arquivo é uma cópia real e de boa qualidade do logotipo original.

A proposta do rel=”logo” é criar um padrão para a publicação de logotipos em vetor na internet que possa ser reutilizado por outros sites, aplicativos, leitores, etc. Desta maneira os usuários poderiam facilmente ter acesso a um arquivo escalável e aprovado pelo dono. E isto facilitaria para que as aplicações sempre tivessem a versão mais atualizada do logo, mantendo a consistência da identidade visual de uma marca.

O padrão foi rejeitado pelo Microformats por ser parecido com rel=”icon”. (Aparentemente eles não sabem distinguir entre ícones e logotipos). Mas isto não desestimulou o uso já que é algo simples de ser aplicado e que não depende muito de atributos como compatibilidade do browser, etc. Alguns serviços grandes como Foursquare e Github já utilizam rel=”logo”.

Basta uma linha de HTML para utilizar rel=”logo” em seu site. O processo é bem similar ao de implementação de um favicon ou um apple touch icon. Para utilizar basta realizar o upload do arquivo SVG em um servidor qualquer e adicionar o seguinte código entre as tags head (obviamente substituindo “seudominio.com.br” pelo endereço do seu arquivo).

<link rel="logo"   type="image/svg"  href="http://www.seudominio.com.br/logo.svg"/>

E pronto! Você pode testar o funcionamento utilizando a API do serviço.

Para o futuro existem ainda projetos para ampliar este conceito. A idéia é incluir formatos diferentes (horizontal, vertical, quadrado), variações de cores (mococromático, colorido, etc) e até mesmo link para um manual da marca em PDF.

Quer gritar para os quatro cantos da web que qualquer um pode baixar seu logo? Você pode implementar uma solução como a do plugin Logo Downloadtip para facilitar o acesso ao arquivo.

a[download]

Colocar um link direto para um arquivo pesado – como um PDF por exemplo – pode ser um desastre. O usuário pode clicar acidentalmente e o navegador travar ao tentar renderizar o arquivo utilizando um plugin… Pedir para “clicar com o botão direito e salvar” também não é uma solução efetiva do ponto de vista da experiência do usuário. Mas através do atributo a[download] você pode forçar o browser a realizar automaticamente o download do arquivo. Existem algumas soluções em PHP para este problema, mas seria muito mais simples se isto pudesse ser resolvido em HTML mesmo, certo?

Existe uma preocupação grande quanto a segurança deste tipo de funcionalidade. É provável que arquivos executáveis não sejam compatíveis com o formato.

Bem, o parâmetro a[download] já existe e está presente nas especificações do HTML5. O problema é a compatibilidade com os navegadores. Por enquanto só o Google Chrome 4+ e o Firefox 20+ aceitam… Mas se você quiser utilizar mesmo assim é bem simples.

<a href="nomedoarquivogigante.pdf" download>Download do Arquivo Gigante</a>

Você também pode especificar um nome através do atributo “download”. Isto é especialmente útil no caso de arquivos com o nome gerado automaticamente, já que o arquivo sera salvo com o nome que você especificou. Não se esqueça de incluir a extensão do arquivo já que o Firefox não coloca ela automaticamente.

<a href="4816162342.pdf" download="arquivogigante.pdf">Download do Arquivo Gigante</a>

Quer testar como funciona? Esta demo do atributo é bem interessante.

Além de baixar automáticamente ao clicar no link, no Google Chrome também é possível arrastar e soltar o arquivo para a área de trabalho.

Seja a mudança que você quer ver no mundo.

Este pensamento aplica-se perfeitamente ao desenvolvimento web. As vezes dependemos muito de padrões, consórcios e associações fechadas para determinar o futuro e esquecemos que nós, desenvolvedores, também temos o poder para criarmos nossos próprios caminhos e fazermos a diferença na comunidade. Iniciativas como rel=”logo” e Responsive Images Community Group são a prova disto.

O post 3 parâmetros de HTML que você deve usar em um futuro próximo foi originalmente publicado em Tableless.

O post Slides para Devs #9 – Acessibilidade na web foi originalmente publicado em Tableless.

Depois de muito esforço, finalmente lançamos um guia definitivo sobre o assunto chamado browserdiet.com e vim compartilhar um pouco da experiência de ter liderado esse projeto irado.

Motivação

O ano de 2012 foi um ano bem diferente pra mim, passei 1/3 dele viajando e me deparei com muita conexão ruim em hotel e aeroporto. Isso me deixava muito irritado. E é claro que eu sempre xingava o hotel/aeroporto, até perceber que a culpa na verdade é nossa.

Nós desenvolvedores somos egoístas. Passamos o dia todo no escritório com uma alta velocidade de conexão e esquecemos que existem outras pessoas no mundo enfrentando velocidades bem diferentes daquela.

O Início

Comecei a estudar mais sobre performance e me deparei com o seguinte cenário. Em inglês, excelentes referências como os livros High Performance Websites e Even Faster Web Sites, ambos do Steve Souders. Além, é claro, dos guias da Yahoo! e Google. Já em português, uma dezena de blogposts soltos por aí.

Pensei: “E se eu fizesse um guia foda de performance voltado pra comunidade?” Mas não fazia sentido fazer aquilo sozinho, então de pouquinho em pouquinho fui conversando com uns amigos.

Concepção

Uma coisa estava muito clara pra mim, queria fazer um projeto divertido.

Convenci primeiro a designer Briza Bueno (Americanas.com) a me ajudar. Ela elaborou uma identidade muito mais divertida do que aqueles guias chatos que existem hoje. Isso tudo com base nas ilustrações do Scott Johnson, a quem eu pedi autorização para utilizar as imagens.

Depois chegou a hora de elaborar a estrutura desse site, nessa parte o Iraê Lambert (Yahoo!) me deu uma mão escrevendo um static generator em Python. Só que eu não dominava aquele código e as barreiras que eu encontrava por não saber manipular aquilo foram me afastando do projeto, ao mesmo tempo em que outras ideias iam surgindo.

Resultado: o projeto ficou parado por 1 ano até que eu decidi retomar reescrevendo todo código usando um outro static generator em Node.JS chamado DocPad. Como todo projeto open source, se você quiser fazer algo que tenha a colaboração das pessoas precisa eliminar o maior número de barreiras possíveis. Por isso, inspirado no HTML5 Please, decidi que todas as dicas seriam escritas no formato mais simples do planeta, em Markdown.

Conteúdo

Design e implementação estavam prontos, só faltava o que realmente importa, o conteúdo. Convidei então grandes amigos que enfrentam muitos desafios de performance no seu dia-a-dia, Davidson Fellipe (Globo.com), Giovanni Keppelen (Peixe Urbano) e Jaydson Gomes (Terra). As categorias iniciais divididas entre nós foram HTML, CSS, JavaScript e jQuery.

Meu eterno dilema entre português e inglês também persistia nesse projeto. Cheguei a comprar o pequenino domínio comoperderpesonobrowser.com.br, mas ele claramente não funcionaria para um conteúdo em inglês também. Por isso, optei por algo mais curto e universal.

Revisão

Depois de muito aprimoramento resolvi convidar outros caras sinistros para revisarem, como o Marcel Duran (Twitter), Mike Taylor (Opera), Renato Mangini (Google) e Sérgio Lopes (Caelum). Todos ficaram animados e contribuiram insanamente. O legal foi que a discussão não ficou apenas na parte do conteúdo, questões relativas ao código do site foram extremamente debatidas como usar CSS Sprites vs Lazy Load.

Lançamento

Eu estava planejando lançar esse projeto no mínimo em Abril. Só que quando vi que os primeiros colaboradores (Briza, Davidson, Giovanni, e Jaydson) do projeto estariam presentes no Rio.JS, mudei o tema da minha palestra e comecei a correr contra o tempo.

Felizmente deu tudo certo e lançamos o projeto!

O resultado final você pode conferir em: browserdiet.com. E o código fonte, como sempre, está aberto no Github.

PS: Os slides também estão online para quem quiser conferir.

Conclusão?

Estou bem animado para ver como a comunidade vai receber e se beneficiar desse aglomerado de dicas iradas que preparamos.

E aí, vamos fazer uma web mais rápida?

Reações

iMasters – Guia que conscientiza desenvolvedores sobre a importância da performance é lançado

love this new project: browserdiet.com

— Stoyan Stefanov (@stoyanstefanov) March 11, 2013

Stoyan Stefanov, Engineer – Facebook

How to lose weight in the browser — the definitive front-end performance guide: browserdiet.com

— Mathias Bynens (@mathias) March 11, 2013

Mathias Bynens, Web Developer – Freelance

Some of Brazil’s brightest front-end devs created and just launched browserdiet.com. Check it out!

— Mike Taylor (@miketaylr) March 11, 2013

Mike Taylor, Web Opener – Opera

O post Como perder peso (no browser) foi originalmente publicado em Tableless.

É claro que você vai precisar abrir mão de efeitos em navegadores antigos (ou, na maioria dos casos, da implementação inteira). É claro também que as implementações são até certo ponto limitadas em comparação a plugins e bibliotecas JavaScript, mas dão um show em performance e otimização.

Botões, galerias/slides, tabs e até mesmo o famoso efeito de lightbox já podem ser implementados sem nenhuma linha de JavaScript. Confira alguns exemplos.

Galeria

http://benschwarz.github.io/gallery-css/

Ben Schwarz caprichou e lançou recentemente uma galeria utilizando apenas CSS3. A galeria permite controles personalizados e vem com uma animação para autoplay.

Os slides podem conter qualquer conteúdo em HTML e o grande segredo por trás dessa galeria é o uso de âncoras (#) aliado a elementos com position:absolute e o pseudo-atributo :target.

O pseudo atributo target é aplicado em elementos referenciados por uma âncora. Por exemplo, sua página tem um elemento section com o id “section-1″ e um link para a âncora #section-1. Quando o usuário clicar nesse link, o CSS definido na regra section:target será aplicado no elemento #section-1.

Lightbox

http://tympanus.net/codrops/2011/12/26/css3-lightbox/

O efeito Lightbox é um dos grandes responsáveis pela popularização do JavaScript e suas bibliotecas. Hoje já existem centenas de clones do original, com diferentes configurações e a versão CSS supera muitas dessas implementações em JavaScript.

Menu Dropdown

http://line25.com/tutorials/how-to-create-a-pure-css-dropdown-menu

Outro elemento bastante popular em JavaScript é o menu dropdown. Sua versão CSS usa apenas o atributo :hover dos links para exibir e esconder os múltiplos níveis de submenus.

Ainda dá para usar algum tipo de transition ou animation para deixar o menu mais atraente. Quem se habilita?

Abas

http://www.sitepoint.com/css3-tabs-using-target-selector/

E que tal uma interface separada por abas sem usar JavaScript? É isso que este tutorial do Sitepoint oferece, mais uma vez fazendo uso do atributo target.

Tooltip

http://kushagragour.in/lab/hint/

Tooltips possuem dezenas de implementações utilizando JavaScript. Sua versão CSS3 usa e abusa dos pseudo atributos :after e :before.

Uma nota importante: as transições nos atributos after e before só foram implementadas recentemente no Chrome (versão 26). Nada que impeça a tooltip de funcionar – ela apenas será renderizada sem animações.

Botões

http://hellohappy.org/css3-buttons/

Não é só JavaScript que pode ser cortado – também podemos parar de utilizar sprites para botões. Hoje em dia já é possível criar botões consistentes e interativos utilizando apenas CSS3.

O designer Chad Mazzola mantém um repositório de botões “que utilizam o markup mais simples possível”. Este é um bom ponto de partida, mas os exemplos de botões utilizando apenas CSS são os mais fáceis de encontrar.

Evento de clique

http://www.ryancollins.me/?p=1041

Esse último exemplo não é bem um elemento, mas sim uma aplicação do evento de clique utilizando o atributo active de um elemento. Com poucas linhas de código é possível exibir/esconder um menu ao clicar em um botão.

E você, já deixou de fazer alguma coisa em JavaScript para implementar utilizando apenas CSS? Diz aí nos comentários!

O post Elementos de interface utilizando apenas CSS3 foi originalmente publicado em Tableless.

• Experiência de uso: UX não é interface ou seu design. UX é processo, interação, satisfação.
• Problema classico de UX no Brasil: vide serviços públicos.
• Contrate os melhores, mas defina o que é o melhor para o seu negócio. Nem sempre os melhores são aqueles com o QI mais alto. Você tem que descobrir o melhor que se adeque ao ciclo do seu negócio.
• Qualidade é Drucker: qualidade é o que o cliente quer, pelo preço que ele pode pagar.
• Contribua para o todo. No caso dos grandes da web, falamos de contribuir com software, política, padrões.
• Princípios culturais: 1. Medir tudo, 2. faça quase tudo, 3. Experiência de uso, 4. recrutamento, 5. contribuir para o todo.
• O que é um time? Time é um certo tipo de rede social. É um conjunto de interações que tem processo de construção, evolução e manutenções próprias, feito de trabalho e pessoas que criam, descobrem e resolve PROBLEMAS.
• O que são times pequenos? De 5 a 12 pessoas, há milhares de anos de história por trás disso. São times pequenos que se focam para resolver problemas grandes, sem burocracia.
  • Na Amazon um time pequeno é igual a 2 pizzas grandes.
  • Na Valve o time é ainda menor. Algo em torno de 1 ou 2 pessoas. A Valve tem o maior valor individual agregado de funcionários. Não existe gestor. Cada um encontra um problema que deve ser resolvida.
• Fazer times que podem ser especialistas em certas funcionalidades. E tome cuidado:
  • 1. Expertise para diferenciação mudou.
  • 2. Diferenciação depende de múltiplas funções.
  • 3. funções se isolam e abandonam o todo.
• Case o desenvolvimento com operações. O time que esclarece, idealiza e desenvolve deve estar casado com o time que implanta, opera e evolui.
• Práticas devem ser usadas de forma síncrona: junto com a cultura, principios organizacionais e da arquitetura do negócio.
• Lean startup: interações rápidas, no campo, para validar os elementos de sua proposta de valor. Prototipar, testar, medir, avaliar e modificar ou descartar.
• Descartar produtos que não trazem valor é algo muito difícil de se fazer.
• Tratar tudo aquilo que se tem **certeza** como **hipóteses** para **comprovar na práticar**.
• MVP é um produto/serviço para ser usado no ciclo de validação LEAN. Deve habilitar o maior aprendizado possível, junto a clientes reais, com o menor dispêndio de energia possível.
• Entrega contínua é entregar produtos e serviços o tempo todo, baseada na teoria das pequenas melhorias.
• Exemplo? Uma mudança por dia no Facebook. Eles entregam mais de uma mudança por dia, para nichos, para parte do sistema, para parte dos usuários. Isso serve para medir, pegar resultados e entender as soluções.
• Método de RIES: simplificar, centralizar, verificar, monitorar e analisar.
• Funcionalidades condicionar. Certas capacidades vão existir, apenas em contextos específicos, senão, como facebook iria prover algo novo com pouco risco inicial? Teste com poucas pessoas, para correr riscos menores e colher resultados importantes.
• Faça testes A/B. É comum, mas ninguém faz. Significa que certas horas, você tem que escolher entre duas alternativas, que podem ser as únicas e talvez você só tenha um e tem dificuldade de encontrar a outra alternativa. Antes de escolher, teste. Crie cenários, descubra o que separa as alternativas. Ofereça a dois grupos distintos. Meça tudo. Avalie. Descarte a alternativa menos efetiva. Vá em frente com a outra alternativa.
• Seja independente de dispositivos. Imagine que o pão de sua padaria só pode ser carregado num saco de um certo formato, que só é feito por uma máquina de um fabricante.
• Em grandes negócios os insumos estruturais devem ser fáceis de usar, abertos para entender, móveis no fazer, sociais com quem mais usa, simples para mudar.
• Viva em modo beta perpétuo: aprendizado contínuo, cooperação e competição constante, nem que seja para saber que sua oferta é ruim. Isso cria oportunidade para melhorar continuamente podendo haver método pra fazer: ouça quem usa, pergunte para entender, mude para atender, aprenda rápido.
• Quanto mais complicado um processo de negócio, maior o risco de ser inexequível, imensurável. Isso devia levar à eterna busca dos genéricos mínimos e combinadores essenciais.
• Desenhe para falhar. Parta do princípio que desenho é uma intervenção no fluxo de negócio. Interfira no fluxo do negócio para sair da situação atual para uma situação desejada.
• TEA: Tentativas, Erros e Aprendizados.
• Não aceitar que haverá erros em tentativas de mudanças, quer dizer que vamos morrer no longo prazo. Aceite os erros no processo de mudança.
• Deve ser possível fazer entregas parciais. O todo deve degradar graciosamente.
• Grandes empresas trabalham em rede, usando a rede, consumindo da rede e provendo para a rede. Seu negócio como parte de uma verdadeira federação.

O post Anotações da palestra do Silvio Meira foi originalmente publicado em Tableless.