O problema a ser resolvido é que se quisermos criar um sistema que utilize algumas facilidades de outros sistemas, nós precisamos aprender a API deste determinado sistema. Acontece que as APIs não são iguais. Se você quer utilizar um sistema de localização como Foursquare ou Gowalla, você precisa aprender como a API de cada um funciona e então escolher entre um dos dois ou utilizar os dois no seu sistema. Nesse caso, você tem o dobro do trabalho para manter seu sistema. Os dois podem modificar partes da sua API e você tem que ficar atento para que seu sistema não quebre. O WebIntents faz com que você consiga usar um comando para os dois serviços.

Web Intents, based on an existing capability in Google’s Android mobile OS, will let Web apps express a simple call for an action, like ‘share’ or ‘edit,’ which receiving apps will be designed to use, without either app needing to have specific knowledge of the APIs of the other. This way, instead of having to code for each specific Web app one might want to access, developers can just use these simple requests, which will be built into the browser. The Chrome and Firefox teams are each building this functionality for their own browser, but they’re combining their proposals to use a single API for Web app developers to reach both platforms.

Paul Kinlan, o dono da ideia e desenvolvedor do Google, explica no em um post no seu blog o que é o WebIntents:

“If I built an image gallery application and I wanted to let users edit an image so that they can remove red-eye from a photo I either have to build an application that edits the images, or integrate with a 3rd party solution. Doing this is hard and stops you from building an awesome image gallery; and what happens if the user has a favorite service that they already use to remove red-eye? Simple, you have a frustrated user.”

Não é de hoje que iniciativas de desenvolvedores e grandes empresas tomam forma para que o desenovlvimento web fique cada vez mais fácil e menos trabalhoso. Isso aconteceu com muitos grupos de desenvolvedores, como o pessoal da WaSP, o pessoal da WHATWG e mais uma vez agora com o pessoal do WebIntents. Claro, existem outras iniciativas anônimas que nos fizeram chegar até aqui.

Eu gosto muito muito de uma frase do pessoal da WaSP utiliza há tempos: If not now, when? If not you, who?

Veja aqui o GitHub do Framework.

Posts Relacionados

• Experiência deve ter começo, meio e fim
• Sobre Internet Explorer para Mobile – Breve impressão
• Mobilidade na cabeça
• Sites para Dispositivos Móveis – Breve introdução
• Browsers dos Dispositivos Móveis

Hoje, aparelhos como o iPhone, que tem um browser com um bom suporte a HTML 5 e CSS 3, possibilitam criar sistemas e aplicativos baseados em web, com características, designs e comportamentos idênticos aos de aplicações instaláveis nos aparelhos. E o melhor, podem ser utilizados de qualquer lugar, pela web. Outro ponto negativo é que desenvolver para iPhone/iPod Touch é um bocado burocrático. Você precisa ter o SDK que só funciona no OS X, e você precisa aprender Objective C para programar os Apps para Apple. Em contrapartida, para fazer um App baseado em Web, onde seus clientes acessarão o sistema diretamente pelo browser do aparelho, é preciso saber Javascript, HTML 5 e CSS 3. Se você já é desenvolvedor Web, você já sabe desenvolver para iPhone, iPod Touch, Android e qualquer outro dispositivo similar.

Se você gosta dos efeitos de transição dos aparelhos, você pode fazê-los sem problemas utilizando JQuery ou CSS 3. Há até um plugin de JQuery chamado JQTouch, que permite fazer efeitos idênticos ao do iPhone. Esse plugin foi pensado exatamente para funcionar em Mobile Safari e outros aparelhos com browsers avançados, como no Android.

Um caso sobre o que estamos falando é a aplicação do Itaú. Se você tem um iPhone, baixe o aplicativo pela AppStore. Ao abrir o aplicativo, perceba que o sistema não faz nada além de mostrar o site do Itaú. É muito mais interessante e barato ensinar o usuário a visitar o site em vez de procurar um aplicativo e instalar. Não é necessário nem divulgar um endereço mobile do site – esse aliás é outra discussão.

Obviamente, há exceções. A maioria dos jogos, se não todos, e alguns sistemas disponíveis funcionam melhor (ainda) se forem instalados no aparelho. Mas a grande maioria dos sistemas, principalmente aqueles que o usuário simplesmente insere ou verifca informações e dados, podem ser servidos diretamente pela web.

No caso do iPhone, os sistemas que utilizam recursos do aparelho, como por exemplo fazer o aparelho vibrar, bluetooth, bateria, GPS e etc, precisam ser instalados. Isso não se aplica a alguns mobiles da Nokia que são baseados na plataforma WRT.
A plataforma WRT permite que você desenvolva aplicativos utilizando Javascript, HTML e CSS. E por meio de Javascript, você pode ativar os recursos que ter utilizar no aparelho. Nesse caso, há uma vantagem em cima do iPhone: você não precisa aprender Objective C. Basta saber Javascript, CSS e HTML.

O cenário de hoje é interessante. Tudo o que o desenvolvedor sempre sonhou em utilizar de HTML 5 e CSS 3 pode ser aplicado no desenvolvimento para web mobile. Os browsers estão mais espertos e a cada dia trazem novidades interessantes para melhorar o desenvolvimento dos padrões e da web. Realmente, daqui pra frente, é um novo mundo que se forma. Um mundo tão ou mais complexo que o desenvolvimento web para desktops como conhecemos hoje. Pra mim, é mais apaixonante.

• Guidelines de User Experience da Apple.
• Forum Nokia – Web Runtime

Posts Relacionados

• Ah, o maravilhoso mundo real
• O que é Tableless?
• Especificação para touch screens
• Bem vindo a Xangri-lá – Parte 2
• 6 dicas para evitar problemas de incompatibilidade entre browsers.

A 1a. Conferência Web W3C Brasil 2009 será realizada em São Paulo, SP, nos dia 23 e 24 de novembro, no Blue Tree Towers Morumbi no bairro do Brooklin. Acesse os links para obter informações sobre o local, hotéis da região, chamada de trabalhos ou sobre como se inscrever para participar da conferência da web brasileira.

Chamada para trabalhos

Você pode ser um palestrante da 1a. Conferência Web W3C Brasil! Se você tem um caso prático e inovador de uso da web, ou fez uma pesquisa cujos resultados merecem ser compartilhados com toda a comunidade web brasileira, ou ainda tem o “pulo do gato” para ensinar em um tutorial, então atenda a nossa Chamada de ‘Papers’, Casos de uso e Tutoriais.

O Comitê de Programa vai selecionar as submissões mais relevantes para compor a programação da Conferência. Mais detalhes em Chamada de trabalhos.

Entre na comunidade da conferência no Facebook e fique por dentro.

Posts Relacionados

• WebIntents – Framework para WebApps
• Processos e Adoção de Padrões
• Porque é a web que comanda
• Prepare-se para a Revolução
• Propriedade do CSS: nth-child

. Ela é mais rica em detalhes sobre o cálculo que essa pseudo-classe faz. Este artigo é para os pobres mortais.

Você já precisou de criar uma tabela zebrada? Eu já, muitas vezes. Provavelmente se você não sabe programar, você precisa chamar um programador para escrever duas ou três linhas de código Javascript ou até mesmo usando JQuery, para fazer a mágica para você. A idéia do CSS, é que nós, designers, possamos controlar a aparência dos elementos HTML. Isso inclui conseguirmos fazer uma maldita tabela zebrada também. Para isso e para outros problemas parecidos, podemos utilizar a pseudo-classe

. Com esta pseudo-classe é possível selecionar um determinado elemento dentro de uma árvore de elementos. Por exemplo, podemos selecionar todas as linhas ímpares das tabela. Legal, hein?

Cálculo básico

O cálculo utilizado pelo

é bastante simples. Você vai usar na maioria das vezes soma. Lembra? A fómula será a seguinte: an+b.

table tbody tr:nth-child(2n+1) {
  background:lightgray;
}

O funcionamento é o seguinte: o browser aplica o estilo a cada 2

.
O código abaixo, aplica o estilo a cada 3

. E assim por diante.

table tbody tr:nth-child(3n+1) {
  background:lightgray;
}

Você pode facilitar, utilizando as palavras odd ou even, para selecionar os elementos ímpares ou pares da árvore.

table tbody tr:nth-child(odd) {
  background:lightgray;
}

Caso você queira pegar 9º, 19º, 29º e assim por diante:

table tbody tr:nth-child(10n-1) {
  background:lightgray;
}

Se o valor de a (an+b) é igual 0, você não precisa colocar a fórmula, apenas o número referente a ordem do elemento. Exemplo:

table tbody tr:nth-child(1) {
  background:lightgray;
}

Neste código, o browser iá colorir o background apenas do primeiro

.

Veja o exemplo.

A propriedade

faz parte dos seletores do CSS 3 e já pode ser utilizado em browsers atuais.

Se você ainda não leu sobre seletores do CSS, leia estes artigos abaixo:

• Seletores encadeados e agrupados
• Seletores do CSS – Pseudo-classes
• Seletores Complexos do CSS

Posts Relacionados

• CSS 3 Columns
• Introdução ao CSS 3D – Flip Card
• CSS3 – Animation e regra keyframe
• Múltiplos backgrounds com CSS
• CSS3 – Abas com a pseudo-classe :target

Durante muito tempo agencias web achavam que o desenvolvedor deveria ser uma espécie de canivete suiço. Lembro-me que haviam empresas que procuravam designers que soubessem duas ou três linguagens server-side e programadores que entendessem bem de photoshop, fireworks e illustrator. Pague o salário de um e leve dois. Contudo, também haviam profissionais que achavam que ele deveria ter exatamente este perfil. Talvez por pressão do mercado ou até mesmo porque ninguém entendia direito esse negócio de web.
Era “chic” você dizer que sabia um pouco de tudo. Mas o tempo mostrou que quem sabe um pouco de tudo na verdade sabe muito de nada. Há problemas que apenas um especialista, acostumado com as peculiaridades de um certo ambiente, pode resolver com maestria. Há coisas que só a faca pode cortar.
Felizmente o mundo girou e a web mudou. Hoje é mais comum encontrarmos empresas que separam os processos. Paga-se mais para ter uma equipe de desenvolvimento web hoje em dia. No lugar daquele profissional meio ou quase nada especialista, você terá uma pessoa focada, concentrada em apenas um tipo de tarefa e está acostumado com essa atividade.

O processo de desenvolvimento web vem sendo modificado durante anos. No começo do desenvolvimento de sites e sistemas para internet eram planejados baseando-se em papel. Passava-se muito tempo planejando um sistema antes de faze-lo. O cliente demorava para ganhar algo de valor e a equipe ficava ocupada prevendo quanto tempo levariam para desenvolver as etapas.
O processo de desenvolvimento também era linear. Geralmente acontecia de a equipe receber o briefing do cliente, que depois era passado para o designer, que faria o layout no Photoshop ou qualquer outro sistema visual. Depois de já desenhado, ele preparia o HTML, normalmente utilizando um editor WYSIWYG. O programador por sua vez, com o código HTML na mão programaria todo o site ou sistema.
Essa forma linear de desenvolver sistemas é algo aterrorizante, traz muitos problemas de manutenção e retrabalho. Se o cliente requisitasse alguma mudança no desenho do layout, o designer teria que refazer todo o HTML que por sua vez seria reprogramado novamente pelo programador. As partes: programação, design e client-side eram totalmente dependentes uma das outras. Uma forma antiga e nada produtiva de se desenvolver.

Com a era dos Padrões Web isso tudo ajudou a mudar. A equipe já havia sido basicamente modificada. Agora, em vez de uma pessoa para fazer design, client-side e server-side, há pelo menos 3 profissionais: um para fazer o design, outro para estruturar o HTML e por fim o programador com o server-side. Essa partes são independentes. Se o cliente mudar de idéia em relação ao design do site, o HTML não precisará ser modificado, logo o programador não precisará reprogramar o site. Será trabalho apenas para o Designer, que terá que refazer o layout e criar um novo CSS. É trabalho para apenas uma pessoa. O resto da equipe poderá se ocupar com outras tarefas.

O caso acima só terá sucesso se em cada uma fases do desenvolvimento houver um especialista por trás. Um “coringa” não conseguiria ser tão ágil porque ele não domina todas as áreas.

Toda essa história também muda a cara do mercado. Profissionais são mais valorizados pelo seu conhecimento, sua experiência e especialização. Os profissionais se tornam mais dedicados com o processo e ganham uma visão muito maior de todo o projeto.

Posts Relacionados

• WebIntents – Framework para WebApps
• Porque é a web que comanda
• 1a. Conferência Web W3C Brasil
• Propriedade do CSS: nth-child
• Web Standards Project – WaSP

Neste começo não brotaram desenvolvedores web do chão. Essa profissão não existia. Os primeiros que trabalharam nessa área, migraram de profissões parecidas: quem era programador desktop naquele tempo, começou a programar para web. Quem era designer de impresso, começou a fazer design para web.

Os desenvolvedores

Os programadores estavam se acostumando com a maneira nova de criar sistemas e sites para web. E designers estavam se habiatuando às diferenças que existiam no design para web e impresso. Haviam muitas coisas para se acostumar, começando pelos erros de compatibilidade.

O W3C

O W3C foi criado para regulamentar e criar padrões para a publicação de conteúdo na web. Quando ele começou, não haviam documentos completos, com listas e regulamentos explicando cada um dos padrões. Esses documentos eram rascunhos, muitas vezes incompletos e com apenas uma descrição do que seria aquele padrão.

Com a falta de documentação completa e detalhada, os browsers aproveitavam para criar códigos proprietários, dificultando o desenvolvimento.

Os browsers

O Netscape (antigo Mosaic), era o browser com a maior base de usuários. Para ser sincero, não haviam muitos browsers concorrentes naquela época. A Microsoft, aproveitou o poder que ganhara com a distribuição do Windows com a IBM, e criou o Internet Explorer para concorrer com o Netscape. Foi aí que a Guerra dos Browsers começou.

A guerra por usuários somada com a falta de padrões resultou em códigos proprietários. Conquiste os desenvolvedores e conquistará a web.

Todo esse tumulto no começo da web fez com que o desenvolvimento de sites se tornasse mais complicado, confuso. Em conseqüência a mão de obra se tornava mais cara e o custo de desenvolvimento também. Era caro comprar um site e era mais caro ainda manter esse site.
Era preciso fazer duas versões de sites: uma para Internet Explorer e outra para Netscape. Qualquer atualização ou alteração de layout, era necessário modificar as duas versões. Isso significava trabalho em dobro, logo o custo aumentava.

A Cavalaria – WaSP

Um grupo de desenvolvedores, na maioria designers, formaram um movimento chamado Web Standards Project – WaSP. Um grupo cuja missão seria divulgar os Padrões Web como guias para o desenvolvimento web. O projeto era encabeçado por profissionais como Jeffrey Zeldman, inconformados com o caminho que o desenvolvimento web estava caminhando. E eles tinham toda a razão.

A primeira grande coisa que fizeram foi convencer a Netscape a doar para a comunidade o engine do Netscape. Um grande feito que se não fosse alcançado, hoje não teríamos a fundação Mozilla com seu browser Firefox.

A segunda missão foi fazer com que os fabricantes de browsers seguissem as idéias e recomendações do W3C.
O diferencial naquele tempo dos browsers era apenas o número de usuários. Não haviam add-ons, interface interligada com serviços sociais, leitores de feeds, nem nada do gênero. Seguir o W3C era dizer adeus ao código proprietário e abrir oportunidades para os desenvolvedores a criarem sites para o browser concorrente.

Outro objetivo do grupo era fazer com que os desenvolvedores também adotassem os Padrões do W3C. E esse objetivo está sendo cumprido até hoje.
A resitência de hoje, não é nada com a resistência encontrada há 5 anos atrás. Os desenvolvedores estão mais aberto às novas propostas e os novos profissionais já começam aprendendo da maneira correta.

Hoje as coisas estão bem mais fáceis. Browsers e desenvolvedores lutam a favor dos padrões. W3C e entusiastas estudam novos padrões e pedem sugestão dos profissionais.
Com o amadurecimento das partes, o conhecimento se renova e desenvolver para web fica mais divertido.

Posts Relacionados

• Ah, o maravilhoso mundo real
• Browsers – Guerra Fria
• Browser Targeting Version
• O que é Tableless?
• Ferramentas de diagnóstico

Conceito de Hipertexto

A HTML é baseada no conceito de Hipertexto. Hipertexto são conjuntos de elementos – que muitos chamam de nós – ligados por conexões. Estes elementos podem ser palavras, imagens, vídeos, áudio, documentos, etc.
Estes elementos conectados formam uma grande rede de informação. Eles não estão conectados linearmente, como se fosse um texto de um livro, por exemplo, que um assunto é ligado ao outro seguidamente. A conexão feita em um hipertexto é algo imprevisto.
O hipertexto permite a comunicação de dados, organizando conhecimentos e guardando informações relacionadas.

Meios de escrita

O Hipertexto é algo diferente dos meios de escrita convencionais. Ela mudou a forma da leitura e escrita tradicional. A impressão, por exemlo, que é um meio no qual estamos acostumados em nosso dia-a-dia, tem um método original para que você absorva a informação ali exibida. Algumas características do texto impresso: Titulos, Sub-títulos, parágrafo de introdução (olho de texto), numeração de páginas, índice, etc. Essas características não servem e nem combinam com o conceito utilizado no manuscrito, que foi feito para leitura rápida e não linear. No manuscrito há uma série de conexões que indicam caminhos para outros livros e notas de rodapé.
São objetivos e maneiras diferentes para tratar formas de leituras diferentes. O hipertexto também modifica a forma com que a pessoa lê e absorve a informação escrita. O hipertexto dá acesso rápido e abundante a informações diretamente ligadas a assuntos e elementos localizados em diversos pontos do texto. É uma forma de leitura diferenciada, não linear e dependente de vários elementos formando uma rede de informação complexa.

Enquanto em um livro você página por página, linearmente, para formar uma rede de pontos que compõe o assunto tratado do livro, em um hipertexto você tem vários assuntos em volta de um único elemento. São elementos interligados, formando uma rede complexa. Cada elemento particular tem por sua vez outros elementos formando outro universo de conexões.

A HTML foi feita baseado neste conceito, que é fácil de ser entendido quando navegamos pela web. No início da internet, os elementos usados para formar um hipertexto eram basicamente o texto e imagens. Esses por sua vez recebem links que levam o usuário para outro ponto, com links relacionados a outros assuntos. Com a internet ficando cada vez mais veloz, hoje é possível utilizar vídeos e áudio como partes destes elementos. Utilizamos ainda muito basicamente o potencial destes dois elementos.
Pesquisadores passados já tentaram criar e adaptar aparelhos e métodos que funcionassem dentro do conceito de hipertexto. Isso era discutido para melhorar a capacidade de estudo e pesquisa de assuntos complexos. Mesmo assim a internet tem se mostrado a melhor forma de utilização do conceito de hipertexto. É uma base onde há contribuição de conteúdo do mundo inteiro, diariamente, com informações ricas e abundantes.
O interessante é que a web ainda é nova e imprevisível.

Posts Relacionados

• Web Standards Project – WaSP
• Metatags – Breve introdução de uso e teoria
• CSS Frameworks ou como desaprender CSS
• Navegabilidade em Dispositivos Móveis
• Porque é a web que comanda

Sou totalmente contra a qualquer coisa que impeça o contato do desenvolvedor com o código. Sou avesso a qualquer tipo de interface que prometa facilitar o desenvolvimento, pelo menos de XHTML e CSS. Lembra daquele papo sobre o desenvolvedor “analbético” de código?

Ainda acho que utilizar editores que suportam Snippets – ou Macros, dependendo do editor – são as melhores formas de se trabalhar se você quer agilidade. Você mantém o contato com o código e agiliza seu trabalho ao mesmo tempo.

Lembre-se de que estamos falando sobre frameworks de CSS e XHTML. Nada de Django ou qualquer outro tipo de framework para linguagens server side.
Esses tipos de frameworks ajudam um bocado o programador. Boa parte do trabalho duro pode ser agilizado por causa destes frameworks. E até concordo que os desenvolvedores utilizem frameworks deste tipo para ajudar em seu trabalho.

O problema é um que eu já comentei com você e já falei bastante em palestras: o programador, muitas vezes é um bicho mais antenado que o designer ou o camarada que cuida de interface. Ele precisa estudar, precisa procurar soluções mais complexas para problemas mais específicos. Por isso, é bom que existam esse tipo de framework para que o trabalho dele seja mais ágil. Ele não vai desaprender a programar.

É importante que o desenvolvedor web saiba que o código é o mestre. Ler, compreender e escrever código é essencial para que tenhamos o controle sobre o projeto. É importante também para que a pessoa se torne um profissional decente e que tenha algum valor (desculpe aos mais fracos de estômago).

• Why don’t use CSS Frameworks
• CSS Frameworks CSS Reset Design from Scratch
• A CSS Framework
• Desenvolvedor “analbético”

Posts Relacionados

• Ah, o maravilhoso mundo real
• Informação e Formatação; As duas camadas de desenvolvimento web
• O que são Media Types do CSS?
• O que é Tableless?
• Produtividade: editores e snippets

Eu, Danilo Medeiros, Thiago Rigonatti, Bruno Torres, Leonardo Faoro e Gui Leite nos juntamos para falar sobre tecnologia, web, tendências, acessibilidade e etc…
Iremos tentar fazer um programa por semana, tentando abordar os assuntos mais recentes, e fazer aquele bate-papo descontraído que vocês já conhecem. E para começar, já publicamos nosso primeiro podcast.

Visite o site do BlogBits para ter mais detalhes ou simplesmente cadastre o nosso feed no seu agregador predileto.

BlogBits Podcast: o podcast mais divertido e informativo que você já conheceu… ou não…

Posts Relacionados

• BlogBits Podcast #3 – Convergência Digital
• WebIntents – Framework para WebApps
• BlogBits #9 – Espaço publicitário: incentivos, mimos e compra de opiniões
• Podcast Tableless #25 – Validação é importante?!
• Podcast Tableless #23 – .mobi

Posts Relacionados

• Porque é a web que comanda
• SEO para iniciantes – O básico
• Anotações sobre SEO
• White, Gray e Black Hats
• SEO – Sitemaps