Vantagens e alguns cuidados a ter na realização de um Focus Group

A atividade seleccionada foi o Focus Group.

Um Focus Group (FG) é uma reunião informal de utilizadores em que são pedidas as suas opiniões sobre um tópico específico. O objetivo é saber quais as perceções, sentimentos, atitudes e ideias dos participantes sobre esse tópico.

Os FG foram concebidos para obter as opiniões das pessoas e não para determinar a força da sua opinião. Os resultados obtidos não são quantitativos nem representativos da população alvo. Estes resultados podem ser usados para fazer a geração de hipóteses para futuras avaliações usando métodos quantitativos e qualitativos (criação de inquéritos ou entrevistas).

Os FG são úteis para identificar os vários pontos de vista existentes, bem como para permitir que os participantes aprendam uns com os outros gerando um sentimento de coesão social. Algumas das vantagens associadas são:

• Feedback rápido por parte dos utilizadores;
• A equipa de desenvolvimento fica com uma ideia das prioridades dos utilizadores;
• Pode surgir a possibilidade de características em que ninguém havia pensado e que até façam sentido.

No entanto:

• Os participantes podem influenciar-se mutuamente, caindo a discussão no comum pensamento de grupo (GroupThink). Uma tendência social para concordar com a opinião mais popular do grupo, em vez de manter a sua verdadeira posição; e
• Falar sobre algo não é o mesmo que fazer ou usar.

Aconselhamos a leitura do Handbook for Excellence in Focus Group Research. Um livro prático e explicativo de como preparar e aplicar esta técnica.

O Projeto

Objetivos do Focus Group

Foram estipulados três objetivos para este FG:

1. Obter e analisar as opiniões sobre questões de usabilidade, funcionalidade e nomenclatura do Portal;
2. Obter e analisar as opiniões sobre conteúdos de algumas áreas do Portal;
3. Obter e analisar as primeiras impressões após a apresentação do Portal.

Equipa log e participantes

A equipa que preparou e realizou o FG era composta por dois moderadores e um observador.

O grupo deste FG era de dimensão mini, composto por 6 participantes, com idades variáveis e habilitações académicas e profissionais variadas, caracterizando este grupo como heterogéneo. O grupo não estava a par do projecto que deu origem ao Portal, mas todos os participantes sabiam que iam para um FG.

O Focus Group foi realizado numa sala preparada para o efeito, com o material de apresentação e registo audio-visual, paredes disponíveis para atividades no decorrer do FG e uma mesa comprida onde todos os participantes conseguiam ter contacto visual entre si.

A sessão de Focus Group

De entre as abordagens possíveis, a metodologia de moderação selecionada para o FG em questão foi baseada na técnica de questionário que se caracteriza por questões abertas. Desta forma, permite-se a honestidade dos sentimentos que emergem, minimizando a influência do moderador e ajudando a eliminar confusões sobre o que foi dito.

A log optou por um FG estruturado, com um estilo de perguntas não-diretivas, embora com um guia de moderação previamente definido e estruturado.

A esta combinação designa-se por Método da Discussão de Grupo Focada.

O livro Focus Group :: A Pratical Guide for Applied Research é uma boa fonte de informação no momento de planear as dinâmicas e as questões a aplicar. Aconselhamos a sua leitura para um aprofundamento deste tema.

Observação e Registo

Estes passos estavam a cargo do observador que ia registando os resultados numa check list preparada previamente para o efeito.

O FG foi também filmado para posterior facilitação do trabalho de análise, com autorização expressa dos seus participantes.

Resultados

Os resultados do FG foram apresentados num relatório escrito.

Ao longo do relatório transcreveram-se algumas citações que descreviam bem as respostas dos participantes e que, no seu discurso direto, poderiam ter mais impacto na percepção do leitor relativamente à opinião, sentimentos ou percepções dos participantes.

Os resultados foram também acompanhados de fotografias das dinâmicas realizadas e dos seus outputs.

Exemplo de resultado obtido numa das dinâmicas realizadas;

A finalizar o Relatório foi apresentada uma análise sobre as principais conclusões retiradas do FG e a validar em outras atividades como Testes com Utilizadores com e sem utilização de Eyetracking e Avaliação Heurística.

Para nós o Scrum veio como uma lufada de ar fresco. Na log foram duas ou três pessoas que começaram a “evangelizar” os princípios do Scrum e a reclamar por uma nova forma de encarar os projetos. Tanto reclamaram que conseguiram! De facto, a gestão de projeto tradicional já não nos permitia evoluir na direção que pretendíamos, pois faltava-nos a agilidade para reagir à mudança.

Não se tratou do Scrum ser melhor ou pior que o modelo waterfall que usámos durante alguns anos. Tratou-se de constatar que para um melhor desempenho e sucesso da nossa atividade, a metodologia que melhor servia os nossos objetivos era, sem dúvida, o Scrum.

Scrum 101

Começámos pelo básico. Perceber os conceitos, os papéis, as responsabilidades, os rituais. Para nós foi muito importante entender os valores e os princípios desta metodologia.

O Scrum baseia-se e advoga os valores do Agile Manifesto que descrevemos aqui:

Indivíduos e interações em vez de Processos e ferramentas

Funcionalidades completas em vez de Documentação extensa

Colaboração com o Cliente em vez de Negociação de contrato

Resposta à mudança em vez de Seguir um plano à risca

Ou seja, os itens à direita têm valor claro, mas os itens da esquerda têm mais importância. E foram os itens da esquerda que inspiraram a nossa mudança. Hoje podemos afirmar que o sucesso do Scrum assenta na compreensão destes valores e de outros que apoiam processos ágeis. Se acreditarem (com muita força) que estes princípios vos vão ajudar a alcançar melhor resultados, o sucesso está (quase) garantido. Se tiverem dúvidas sobre estes princípios, mais vale despenderem o tempo necessário para debaterem se o Scrum é ou não a metodologa que melhor se adapta à vossa empresa.

Outro desafio foi o assumir novos papéis. Não vale a pena querer iniciar o Scrum na sua empresa se não estiver disposto a mudar os papéis. Ao princípio estranha-se mas depois, já toda a equipa está familiarizada com os seus novos roles. São eles:

• Product Owner: responsável pelo projeto, ou como costumamos lembrar à nossa equipa… é quem tem o pescoço a prémio! :)

• Scrum Master: garante que a equipa é funcional e produtiva. E acreditem, um bom Scrum Master faz o vosso projeto correr sobre rodas!

• Development Team: organiza-se para realizar as suas tarefas. Estes são os talentos! Uns mais experientes, outros menos, mas todos fazem a “magia” acontecer.

• Stakeholders: todos aqueles que beneficiam ou promovem o desenvolvimento do produto. É para eles que criamos e desenvolvemos as nossas soluções.

No próximo artigo vamos falar de Cerimónias e Artefatos.

Até breve!

O Scrum entrou na log há 3 anos e, num misto de entusiasmo e inexperiência, entrámos a fundo na prática do “ScrumBut”. Conhecem o conceito? Uma prática que não cumpre todos os requisitos da framework e que a longo prazo, não permite atingir os benefícios esperados. Olhando para trás, não restam dúvidas: foi um “But” com todas as letras!

Para perceberem melhor do que falamos, no primeiro projeto da log desenvolvido em Scrum a equipa era constituída por um Developer e um Scrum Master. Esperem! Falta um pormenor nesta história: o Developer e o Scrum Master eram a mesma pessoa!

Felizmente, cedo nos apercebemos que é preciso avaliar constantemente o nosso desempenho e saber identificar os erros que foram cometidos e ultrapassá-los. Sempre. Os Sprint Retrospective tiveram, para isso, um papel fundamental.

O nosso caminho tem sido caracterizado por uma aprendizagem que nos tem levado a optimizações e alinhamentos constantes, especialmente nas nossas equipas mas também nos nossos clientes. Agora, passados 3 anos temos equipas totalmente alinhadas aos processos e rituais do Scrum e, mais importante, aos resultados que esta metodologia permite obter em projetos de desenvolvimento de software.

E como o Scrum é feito (acima de tudo) de experiências, vamos partilhar as nossas aqui no blog. Vamos falar das falhas que cometemos e de como as resolvemos, as nossas aprendizagens passadas e seguramente, as que ainda virão.

E sim…é possível passar de um “ScrumBut” para simplesmente…Scrum.

Como? Estes dispositivos, que lançaram a moda dos ecrãs tácteis, hoje ubíquos, fizeram o impensável e, graças à qualidade das suas interfaces e da experiência do utilizador, dispensaram a necessidade de teclados físicos e da maior parte dos botões. Tudo muito bonito para quem vê bem, mas estes dispositivos não oferecem qualquer resposta táctil para além do motor de vibração no iPhone.

O iOS, o sistema operativo que corre em quase todos os dispositivos móveis da Apple, permite definições de contraste, tamanho de letra e zoom, certamente úteis para quem tem algumas dificuldades visuais, mas que nada servem a uma pessoa com problemas mais sérios, incluindo quem não vê absolutamente nada.

Como, então?

VoiceOver

O segredo está na tecnologia VoiceOver, migrada do OS X para prestar feedback auditivo aos utilizadores de iOS com problemas de visão. Graças ao VoiceOver, e agora também à assistente pessoal digital Siri, até pessoas completamente cegas têm acesso facilitado aos dispositivos da Apple e a um grande leque de aplicações.

O VoiceOver não é um produto adquirido à parte. Está integrado em todos os dispositivos iOS e pode ser activado abrindo a aplicação de Settings, e escolhendo General > Accessibility > VoiceOver > On. Também é possível configurar o VoiceOver para ser activado com três toques no botão de Home do dispositivo.

Com o VoiceOver ligado, constatamos de imediato que a interface adquire um comportamento estranho e se torna algo frustrante de usar. Um toque em qualquer parte do ecrã apenas selecciona o elemento tocado, despoletando uma descrição auditiva, sendo que para o activar é preciso um duplo toque no ecrã. E fazer subir ou descer os conteúdos no ecrã obriga a arrastar com três dedos. Mas também nos apercebemos, como que numa revelação, que passamos a poder usar o iOS literalmente de olhos fechados.

As restantes diferenças não são assim tantas: um utilizador do VoiceOver apoia-se na mesma memória muscular e espacial da maioria, e, tal como a maioria, é capaz de varrer rapidamente o ecrã com os dedos para encontrar o que procura, saltando por cima de tudo o que não lhe interessa.

O VoiceOver dá ainda acesso ao “rotor,” um controlo activado pela rotação de dois dedos no ecrã para ajustar a granularidade com que o VoiceOver percorre os elementos da interface, possibilitando saltar entre letras, palavras ou frases, links, campos de formulário ou secções de conteúdo.

No vídeo abaixo, o programador Robin Christopherson sobe ao palco para demonstrar como usa o iPad com VoiceOver no seu dia-a-dia.

Atributos de acessibilidade

Todos os controlos e views do UIKit no iOS implementam protocolos de acessibilidade com atributos que podem ser facilmente definidos a partir do Interface Builder ou no código da aplicação. Estes atributos são:

Label: Rótulo curto que identifica o elemento, idealmente descrevendo a sua função;

Traits: Uma ou mais características pré-definidas descrevendo o estado ou comportamento do elemento (se é um botão ou uma imagem, se está seleccionado ou inactivo, etc.);

Hint: Texto opcional para esclarecer, de forma sucinta, o resultado de activar o elemento;

Value: O valor actual do elemento, caso não se encontre já descrito pelo rótulo;

Frame: A moldura do elemento consiste num par de coordenadas que especificam a posição e dimensões do elemento;

Language: O idioma do elemento, caso a descrição precise de aparecer num idioma que não o configurado.

No vídeo abaixo, podemos observar a utilização da nossa aplicação EatOut com o VoiceOver ligado. Aqui, a acessibilidade do botão para marcação telefónica em iPhone foi optimizada com descrições da label e da hint.

Para quê este trabalho todo?

Na verdade, tornar uma aplicação acessível implica muito pouco esforço. Isto deve-se em parte à qualidade da API do VoiceOver, que por omissão torna acessíveis todos os controlos do UIKit, sendo que nos restantes casos não é preciso mais do que encontrar descritivos apropriados para os atributos de cada um dos elementos da interface.

No caso do EatOut, não foi preciso fazer nada para optimizar a pesquisa de restaurantes para utilizadores com necessidades especiais. A acessibilidade do campo de texto e do teclado foi completamente garantida pela framework sem obrigar à escrita de uma linha de código ou definição de um parâmetro que fosse.

Assim sendo, por que não tornar uma aplicação acessível? Ao cuidar da acessibilidade das nossas aplicações, estamos a levá-las a um público maior. Estamos a oferecer a mesma experiência de utilização a toda a gente, não obstante as limitações e necessidades físicas de cada um. Satisfazemos ainda requisitos de acessibilidade que organismos governamentais por vezes impõem. E, ao mesmo tempo, estamos a tornar uma boa aplicação numa aplicação ainda melhor.

Além disso, uma boa acção não devia ser motivo suficiente?

Boas práticas

Como disse, é muito fácil tornar uma aplicação minimamente acessível, e só costuma falhar quem não se preocupou sequer com o assunto. É frequente aplicações adoptarem controlos alternativos para personalizar aspectos da interface que o UIKit não permite alterar, e quando isso acontece a questão da acessibilidade é por vezes esquecida.

Controlos alternativos que não sejam baseados em UIKit, e por isso não herdem atributos de acessibilidade por omissão, podem implementar os protocolos UIAccessibility e/ou UIAccessibilityContainer para gozar de todos os benefícios de acessibilidade de um controlo oficial.

Independentemente dos controlos usados, as boas práticas de acessibilidade centram-se na qualidade das descrições das labels e hints, e na correcta definição dos traits dos elementos.

As descrições preferem-se concisas: da mesma forma que muitos não olham atentamente para as mensagens dos alertas e para os rótulos de botões, também é provável que um utilizador com VoiceOver não vá ficar a ouvir longas descrições de elementos.

A label deve descrever a função do elemento, de preferência um verbo como “Pesquisar” ou “Fechar”, e não o elemento propriamente dito. “Botão de pesquisa” já é informação em excesso, até porque o trait pode já indicar tratar-se de um botão, o que levaria o VoiceOver a descrevê-lo como “Botão de pesquisa. Botão.”

A hint deve ser usada com parcimónia. Por exemplo, quando a label não é suficientemente explícita, a hint pode esclarecer o resultado de activar o elemento. Por exemplo: “Filtros. Botão. Abre o painel de opções de pesquisa.”

Para além da definição destes atributos, que suprem as necessidades da grande maioria das aplicações, também é possível ajustar a interface para responder ao estado do VoiceOver e à sua eventual activação. Detectar o estado do VoiceOver é particularmente útil quando pretendemos aumentar a perceptibilidade de certos elementos da nossa interface. Por exemplo, uma mensagem de erro que apareça por breves segundos pode e deve ser lida ao utilizador se este tiver VoiceOver.

Detectar o estado do VoiceOver

No EatOut, oferecemos uma funcionalidade de pull-to-refresh em todas as tabelas com conteúdos dinâmicos. Embora a funcionalidade em si seja acessível, usando três dedos para deslocar o conteúdo para lá do limite superior, o VoiceOver torna a sua existência pouco perceptível e o acesso moroso.

Assim, decidimos que, ao activar o VoiceOver, o utilizador deva ser presenteado com um atalho de refrescamento no canto superior direito.

A detecção é feita no código recorrendo à classe NSNotificationCenter do iOS, sendo suficiente associar um método (didChangeVoiceOverStatus: neste exemplo) à notificação UIAccessibilityVoiceOverStatusChanged.

Podemos obter o estado do VoiceOver invocando a função UIAccessibilityIsVoiceOverRunning(), que retorna YES ou NO caso esteja ou não activo.

Convém lembrarmo-nos de retirar o observador da notificação quando já não precisarmos dela, para evitar falhas e fugas de memória:

Conclusões

Tendo em conta a rapidez e facilidade com que a framework do iOS pode garantir o acesso a pessoas com deficiências visuais, torna-se difícil justificar o motivo de tantas aplicações de primeira linha negligenciarem este aspecto da utilização.

Como vimos, a simples definição de um ou dois atributos de acessibilidade em cada controlo é quanto basta para tornar uma aplicação usável e acessível por todos. Mesmo funcionalidades avançadas, dependentes da detecção do estado do VoiceOver, não são particularmente onerosas de implementar.

Para mais informações sobre estes tópicos, recomendamos a leitura da documentação no site da Apple, indicada abaixo.

Referências

• Accessibility Programming Guide for iOS, Apple
• Accessibility for iPhone and iPad apps, por Matt Legend Gemmell

Proporcionar uma experiência única e ter um site com um design apelativo são fatores que irão garantir que o utilizador realiza o “call to action” tão ambicionado por quem desenhou a arquitetura de informação do site.

Atrair muito tráfego para um website não pode ser entendido como uma estratégia isolada. É igualmente necessário garantir uma excelente experiência de utilização aos seus visitantes.

Qual o propósito de obter muito tráfego, se depois, devido a uma má experiência de utilização, os utilizadores abandonam rapidamente o site, sem que consigam cumprir os objetivos que inicialmente tinham em mente quando entraram no site?

Todos ambicionam que o seu site atraia o maior número de pessoas, uma vez que mais pessoas, pode ser sinónimo de crescimento e de novas oportunidades. É isso que faz com que muitos olhem para o SEO como uma resposta às suas necessidades. Mas na ânsia de subir no ranking dos motores de busca, tende-se a ignorar a importância da usabilidade como um fator que também melhora a qualidade do tráfego do site.

Uma vez que os motores de busca estão cada vez mais inteligentes e conhecem cada vez melhor a nossa maneira de pensar, a optimização de um website torna-se um processo mais refinado, permitindo melhorar a usabilidade e o SEO.

De seguida são apresentados 10 pontos importantes para melhorar o SEO e a usabilidade de um site.

1. Tag <head>

Para o SEO esta é a secção mais importante da estrutura do HTML.

Nesta tag são inseridas a tag <title>, as <meta> descrições e ainda as meta tags e a tag rel=”canonical”.

Do ponto de vista da usabilidade, esta tag pode não parecer muito importante, uma vez que esta secção não vai afectar o aspecto visual do site (excepção à tag title). No entanto, este é o conteúdo que irá aparecer, na maioria das vezes, no Search Engine Results Page (SERP). Se o conteúdo desta secção parecer pouco profissional, os utilizadores não se irão sentir tentados a clicar para aceder ao site.

Os motores de busca utilizam o conteúdo das meta tags na secçãode forma a decidirem que informação mostram. Por isso, é necessário torná-la o mais claro e usável possível.

2. Tag <title>

A tag <title> é utilizada pelos motores de busca para determinar o assunto da página. É esta tag que é mostrada na página de resultados (SERP) e é onde os utilizadores podem clicar para aceder ao site.

O conteúdo da tag <title> deve refletir o conteúdo da página. Com esta regra em mente, colocar as palavras chave no início da tag <title> dá-nos um título que é amigo dos motores de busca.

Após efetuar uma pesquisa e obter como resultado uma lista de sites, o utilizador vai ler o texto colocado nesta tag <title> para melhor identificar os sites que lhe são apresentados nesta lista de resultados.

Por outro lado, os web browsers usam o texto desta tag para nomear a tab onde o site se encontra, o que permite ao utilizador identificar rapidamente a tab que contém o site que pretende consultar.

Por norma, os browsers atribuem o conteúdo do título aos favoritos, pelo que os utilizadores também irão procurar pelo título os sites que colocaram nos favoritos.

3. <Meta Name=”Description”

Os motores de busca utilizam o conteúdo da tag <Meta Name=”Description” para mostrar a descrição do site no SERP. Os motores de busca têm um limite de caracteres para mostrar no SERP, não devendo exceder os 160 caracteres.

Embora o Google não utilize o conteúdo das meta tags para elaborar o ranking, a presença de palavras-chave na meta descrition pode gerar tráfego uma vez que pode captar a atenção dos utilizadores.

Do ponto de vista do utilizador, uma meta description, para cada uma das páginas, que corresponda ao conteúdo dessa página e que seja única para cada página, pode fazer toda a diferença em termos de SEO. Pois se os utilizadores, ao verem o mesmo conteúdo da meta description no SERP para todas as páginas, podem ter problemas em identificar qual o link a clicar.

Pelo contrário, se os utilizadores acederem ao site através do SERP, e se o conteúdo da descrição for apelativo mas o resultado da página for diferente da sua expectativa, então isto irá ter um efeito muito negativo na experiência de utilização.

4. Rel=”Canonical”

Uma página canonical é a forma de “comunicar” que o conteúdo da página é o original. Se existirem várias páginas cujo conteúdo é bastante parecido, apenas com pequenas variações, definir um URL como canonical pode resolver o problema do conteúdo duplicado. Conteúdo duplicado é extremamente penalizado pelos motores de busca.

Para os utilizadores, terem páginas com conteúdo idêntico é um factor que os confunde. Se o conteúdo duplicado estiver presente em links ou na navegação do site, irá ser muito difícil para os utilizadores escolherem qual o link a clicar. Isto pode também ocorrer se o mesmo conteúdo é acedido através de links com nomes diferentes, uma vez que na mente dos utilizadores o conteúdo deveria ser diferente.

5. <A Href=”

Os links são essenciais para os motores de pesquisa. Juntamente com os sitemaps XML, eles representam a única forma dos crawlers localizarem e indexarem as páginas. O Google utiliza o link juice, para determinar o “valor” dos links para o ranking.

Para que os links sejam “amigos” dos motores de busca, precisam de ser descritivos e conter as palavras-chave corretas.

Para os utilizadores, existirem links usáveis significa que podem mais facilmente atingir o objectivo com o qual entraram num site (seja com o propósito de fazer uma pesquisa informativa ou uma compra de produtos ou serviços). O facto de o utilizador conseguir atingir o objectivo afeta positivamente a experiência de utilização, aumentando a probabilidade do utilizador voltar ao site ou recomendá-lo a outras pessoas.

6. <Link Rel=”Stylesheet”

Os motores de busca penalizam websites que são lentos a carregar. Quando o JavaScript e as CSS estão nos ficheiros HTML, estes ficheiros ficam com um tamanho maior, o que faz com que o carregamento do ficheiro seja mais lento.

Uma boa solução é colocar o código do JavaScript e das CSS em ficheiros externos, e chamá-los só quando são necessários. Ainda melhor, será comprimir os ficheiros de forma a que tenham um tamanho mais reduzido.

Minimizar o número de pedidos ao servidor, encontrando o equilíbrio entre o número de ficheiros e o seu tamanho também pode melhorar a velocidade do site.

Os utilizadores passam entre 10 a 20 segundos numa página web a não ser que o conteúdo seja relevante para eles. Podemos imaginar o quão rápido os utilizadores abandonariam um site se a página demorasse uma eternidade a carregar. Um estudo elaborado pela Google que os “sites rápidos fazem com que os utilizadores fiquem agradados com a experiência” e que “quando um site é lento a responder, os visitantes passam menos tempo nele“.

7. Microdata

A informação contida na microdata é uma das três linguagens utilizadas (1) para dar informação do conteúdo aos motores de busca. O formato da microdata, schema.org, foi adotado pela Google, Bing e Yahoo!. A microdata fornece informação contextual aos motores de busca e a forma como o site deve ser indexado.

Adicionalmente, também cria “rich snippets“, que fornecem mais informação no SERP do que as listas tradicionais.

Como a microdata fornece aos motores de busca informação mais detalhada do site, estes podem apresentar resultados com mais informação no SERP. Implementar a microdata é benéfico para um início positivo na experiência de utilização mesmo antes de acedermos ao site.

8. Densidade do conteúdo

O conteúdo de um site deve ser cativante e permitir que os utilizadores atinjam os objectivos com que acederam a um site. Embora pareça uma tarefa muito complicada, tudo isto deve ser feito de uma maneira curta e sucinta. O que nos leva ao conceito de densidade do conteúdo.

A densidade do conteúdo é o rácio de conteúdo de uma página em relação ao tamanho dessa página. Páginas com uma grande densidade tendem a ter um melhor ranking nos motores de busca. Por exemplo, se a página A tem 200 palavras e tem 10Kb de tamanho, é provável que tenha um melhor rank em comparação com a página B que tem 200 palavras mas pesa 20Kb.

Do ponto de vista da usabilidade, o conteúdo de uma página deve ser claro e objectivo. Se uma página contém muitos parágrafos, irá perder os seus leitores. A maioria dos utilizadores percorrem uma página à procura da informação. Se não a conseguirem localizar facilmente, desistem e abandonam a página.

A densidade do conteúdo é importante para o SEO e por isso, os sites que se preocupam com este ponto normalmente possuem mais conteúdo que contém palavras-chave e que é fácil de compreender. Disponibilizar as palavras-chave corretas e disponibilizar um conteúdo que seja de fácil leitura, ajuda a obter melhores rankings nos motores de busca.

Os sites que têm demasiado conteúdo podem dificultar o trabalho aos motores de busca, e sites que contêm demasiadas palavras-chave (Keyword Stuffing) oferecem, muito provavelmente, uma experiência de utilização negativa e, por isso, descem no ranking dos motores de busca.

Para os utilizadores, um site que tem as principais palavras-chave de forma moderada é bom para a usabilidade desse site. Os utilizadores podem facilmente identificar se o conteúdo é relevante, e continuar a ler, se for o caso.

Resumidamente, quando os utilizadores visitam um site, estão à procura de conteúdo relevante. Quanto mais tempo eles demorarem a encontrar e a compreender o conteúdo, menos usável se torna o site.

9. Utilização dos Breadcrumbs

A navegação por breadcrumbs é bastante útil nos sites e constitui uma oportunidade de SEO para tornar o site mais amigável para os motores de busca.

Jakob Nielsen concluiu em 2007, que os breadcrumbs têm aumentado a sua utilidade deste 1995.

Do ponto de vista da usabilidade, os breadcrumbs:

• Permitem ao utilizador ter um rasto da sua navegação, podendo voltar atrás, ou mesmo ao ponto de partida da navegação;
• Permitem que os níveis superiores do site fiquem à distância de um clique;
• Diminuem a taxa de rejeição.
• São facilmente entendidos pelos utilizadores.

Do ponto de vista do SEO, os breadcrumbs:

• Constituem uma forma natural de colocar palavras-chave na página, o que ajuda na densidade de palavras-chave;
• Informam e definem, para os motores de busca, qual o conteúdo das páginas do site;
• São bastante relevantes para o Google.

10. Links Internos

Uma interligação de links efectiva e uma utilização de links com significado torna um site usável, o que melhora o ranking nos motores de busca. Investir algum tempo para criar bons links no início de um projecto, irá, ao longo dos tempos, trazer resultados muitos positivos.

Sendo o objectivo de um site atrair utilizadores, quando eles chegam ao site, se não encontram forma de prosseguir e obter a informação que procuram, a experiência de utilização é má e o mais provável é o utilizador não voltar a aceder a esse site.

Criar links que levem os utilizadores a clicar é, todavia, discutível. Alguns autores argumentam que os links devem conter o texto da âncora, o que contribui enormemente para o SEO. Outros, dizem que o texto deve apenas conter um “Call to Action“. Ambos os argumento são válidos, mas o volume de tráfego e os cliques em conteúdo relevante é, em última análise, o interesse máximo de quem construiu o site.

De forma a manter os links atualizados, devemos criar links que se integrem no conteúdo da página. Os links devem dar uma pista aos utilizadores para onde se destinam. Qualquer link que seja ambíguo provavelmente nunca será clicado. Devemos também utilizar o maior número de palavras ou frases para indicar para onde será redirecionado o utilizador, quando clicar no link.

(1) As três linguagens são: Microdata, Microformato e RDFA

A internacionalização (também conhecida pela abreviatura i18n) consiste em assinalar determinadas cadeias de caracteres — ou strings — apresentadas ao utilizador de modo a que estas possam ser traduzidas por um mecanismo transversal à solução. No caso do WordPress, esse mecanismo está presente na biblioteca livre open source do GNU gettext.

A internacionalização deve ser uma consideração a ter desde o primeiro instante do desenvolvimento. Nunca é demais repeti-lo. Uma equipa minimamente interessada em entregar uma solução localizável — seja para melhorar a integração com o eco-sistema aplicacional, aproximar-se dos clientes que já tem ou alcançar novos mercados — não pode encarar a tarefa de internacionalização como uma preocupação secundária.

Primeiro, porque o tempo e o custo de integrar mecanismos de tradução num projecto já iniciado ficam consideravelmente maiores, que mais não seja pelo esforço de localizar no código do projecto todas as strings passíveis de tradução, mas também pelo impacto que quaisquer revisões arquitecturais possam ter.

Segundo, porque o esforço de deixar uma string preparada para tradução, mesmo que depois não se faça nada com ela, é mínimo. Aqui basta a disciplina de envolver o texto a traduzir com uma das várias funções disponibilizadas para o efeito pelo WordPress.

Funções de tradução do WordPress

O WordPress oferece um conjunto de funções para processamento de texto, das quais as mais recorrentes são __() e _e(). A diferença entre as duas é simples: __() retorna a string traduzida para processamento posterior, ao passo que _e() apresenta imediatamente a tradução.

Assim, onde antes faríamos echo, devemos passar a usar _e():

<?php
echo 'Hello, world!'; // Antes
_e( 'Hello, world!' ); // Depois
?>

De modo semelhante, devemos transformar as atribuições de todas as strings traduzíveis com __():

<?php
$greeting = 'Hello, world!'; // Antes
$greeting = __( 'Hello, world!' ); // Depois
?>

Como se pode constatar, não só o impacto na legibilidade é mínimo, como agora sabemos exactamente que texto do nosso projecto está a ser traduzido, bastando efectuar uma pesquisa por “__” ou “_e”. Adiante veremos que existem ferramentas concebidas para varrer o código do projecto e recolher de forma automática todas as strings passíveis de tradução.

As funções de tradução também não se ficam por estes dois exemplos. Outras há, menos comuns mas nem por isso menos úteis, que iremos abordar ao longo do artigo.

Domínios de texto

As funções acima apresentadas aceitam um segundo parâmetro que diz respeito ao identificador do domínio textual. Por omissão, a plataforma assume o identificador “default”, mas recomenda-se que plugins e temas declarem domínios de texto próprios para evitar colisões com as traduções de outros componentes.

As funções que declaram o domínio textual são também as usadas para carregar os ficheiros de tradução no WordPress: load_plugin_textdomain() para os plugins e load_theme_textdomain() para os temas.

<?php
load_plugin_textdomain( 'my_plugin', false, $relpath );
_e( 'Hello, world!', 'my_plugin' );
?>

O primeiro parâmetro é o identificador do domínio, que se quer único para toda a solução, e deverá ser usado em todas as funções de tradução do plugin. O parâmetro do meio não é usado, mantendo-se a posição apenas por questões de retrocompatibilidade. Por fim, a variável $relpath é o caminho, relativo a WP_PLUGIN_DIR, da directoria que contém os ficheiros de tradução com extensão MO.

A função load_plugin_textdomain() carrega todos os ficheiros aí encontrados que correspondam ao formato <textdomain>-<locale>.mo, em que <textdomain> é o domínio declarado acima e <locale> o identificador de cada idioma, composto pelo código ISO 639–1 da língua, seguido por um underscore (_) e pelo código regional ISO 3166–1 em maiúsculas. Por exemplo, um plugin com o domínio de tradução “my_plugin” teria um ficheiro de tradução chamado my_plugin-pt_PT.mo para português de Portugal e outro my_plugin-pt_BR.mo para português do Brasil.

<?php
load_theme_textdomain( 'my_theme', $abspath );
_e( 'Hello, world!', 'my_theme' );
?>

Com load_theme_textdomain(), indicamos à mesma o identificador de domínio, e o caminho absoluto para os ficheiros de tradução do tema. Recomenda-se que esta função seja invocada no contexto da acção after_setup_theme.

Ao contrário do que sucede com os plugins, os ficheiros com as traduções dos temas não podem conter o domínio textual no nome. Aqui, independentemente do domínio, os ficheiros devem chamar-se pt_PT.mo para português de Portugal, pt_BR.mo para português do Brasil ou de_DE.mo para alemão.

Ainda a propósito dos domínios, Geert De Deckere apresenta no seu blogue algumas sugestões interessantes sobre como tornar um plugin mais tolerante a traduções personalizadas.

Um, dois, três…

A necessidade de ter descrições separadas para formas singulares e plurais da apresentação de quantidades é um aborrecimento que qualquer programador já conhece.

Por vezes implica codificar uma simples estrutura de decisão, que mais não seja recorrendo a operadores ternários, mas que diminui a legibilidade do código. Outros sacrificam a atenção ao pormenor usando 1 string(s) genérica(s) para todas as quantidades.

O desafio é complicado ainda pela necessidade de as traduzir, em particular se pensarmos que há idiomas com regras específicas e mais do que duas flexões de número (como o russo ou o árabe).

Para endereçar este problema, o WordPress tem a função _n(), que retorna uma string traduzida em concordância de número com o valor que lhe for passado:

<?php _n( $singular, $plural, $number, $domain ); ?>

Não obstante a existência de idiomas com mais do que duas flexões de número, a função apenas aceita parâmetros para singular e plural. Não há qualquer problema, apesar de tudo. O próprio gettext consegue desmultiplicar todas flexões necessárias a partir daqui, ao passo que o WordPress limita-se a assumir que a codificação das strings originais é feita num idioma com regras gramaticais próximas das do inglês.

Variáveis

O primeiro desafio da utilização de strings de tradução surge quando se tenta traduzir texto contendo uma ou mais variáveis. Cedo descobrimos que interpolação…

<?php _e( "I love the $language language." ); ?>

…não funciona. O tradutor recebe “I love the $language language.” para traduzir, mas a variável não é substituída.

Posto isto, o primeiro impulso do programador pode ser tentar uma resolução por concatenação:

<?php _e( 'I love the ' . $language . ' language.' ); ?>

Mas o resultado seria igualmente desastroso.

Quer estejam interpoladas ou concatenadas, não se devem traduzir strings que contenham variáveis. O software que recolhe as strings para tradução não tem capacidade para interpretar o seu valor. As funções de tradução esperam receber strings literais e não suportam a tradução de valores guardados em variáveis ou constantes.

O programador pode tentar ainda separar a frase onde quer que ocorram as variáveis, assim:

<?php _e( 'I love the ' ); echo $language; _e( ' language.' ); ?>

E estaria absolutamente incorrecto. Porquê?

Para bons entendedores

Porque, no capítulo das boas práticas, recomenda-se que as strings de tradução consistam em frases completas e que se evitem orações ou palavras isoladas. A fragmentação das frases é um obstáculo para que muitas sejam convenientemente traduzidas. Veja-se o (mau) exemplo anterior:

<?php _e( 'I love the ' ); echo $language; _e( ' language.' ); ?>

O primeiro problema é que os tradutores se irão deparar com dois fragmentos isolados e descontextualizados (“I love the” e “language.”), encontrando natural dificuldade em interpretá-los.

Em segundo lugar, o idioma de destino não tem de responder às mesmas regras gramaticais que o de origem. Não cabe na cabeça de ninguém traduzir “I love the” por “Adoro a língua” e depois substituir “language.” por um ponto final, até porque estes fragmentos podem traduzir-se de outra forma noutros contextos.

Um terceiro problema decorre de ter espaços no início ou no final das strings. Estes são difíceis de detectar pelos tradutores, aumentando a probabilidade de erros escusados no produto final.

O procedimento correcto nestas situações é usar as funções printf() ou sprintf() com tokens de substituição para incluir variáveis:

<?php
_e( "I love the $language language." ); // Incorrecto…
_e( 'I love the ' . $language . ' language.' ); // Incorrecto…
_e( 'I love the ' ); echo $language; _e( ' language.' ); // Incorrecto…

printf( __( 'I love the %s language.' ), $language ); // CORRECTO!
?>

Aqui, uma possível tradução portuguesa seria “Adoro a língua %s.” havendo uma posterior substituição do token %s pelo conteúdo da variável.

Contextualização de traduções ambíguas

No seguimento do exemplo acima, vamos supor que a variável $language é preenchida com o valor obtido de um formulário contendo as seguintes opções (traduzidas):

• __( 'English' )
• __( 'Portuguese' )
• __( 'French' )

Embora se trate de uma substituição directa em inglês, ocorrem várias dúvidas na hora de traduzir estas palavras. “Portuguese” representa um substantivo ou um adjectivo? Refere-se ao género masculino ou ao feminino? É singular ou plural?

É essencial contextualizar estas strings e, para isso, o WordPress tem definida a função _x(). Livres de ambiguidades, as strings traduzidas com _x() teriam o seguinte aspecto:

• _x( 'English', 'I love the X language' )
• _x( 'Portuguese', 'I love the X language' )
• _x( 'French', 'I love the X language' )

A descrição contextual do segundo parâmetro deve evitar referências à gramática. Indicar, em vez do contexto, que se trata de um “adjectivo feminino singular” não significa nada para certos tradutores e pode induzir outros em erro. Há línguas em que o conceito de adjectivo não existe. Noutras, a tradução do adjectivo pode ser uniforme, não ter género ou nem sequer ser um adjectivo. E, como já vimos, pode haver diferentes regras para as flexões numéricas.

Estas não são as únicas funções de tradução que o WordPress deixa ao dispor das equipas de desenvolvimento. Existem variações que combinam a funcionalidade das anteriores: _ex(), por exemplo, imprime uma tradução contextual, e _nx() retorna o texto de uma tradução contextual com flexão numérica. Como é hábito, recomendamos a consulta do Codex ao programador que melhor queira conhecer as ferramentas ao seu alcance.

Tradução de HTML

A inclusão de estruturas HTML no texto a traduzir deve sempre ser ponderada. Embora seja prático e até recomendável incluir tags com semântica relevante, como <strong> ou <em>, nem todo o HTML deve ser exposto aos esforços dos tradutores.

<?php _e( '<div>Hello <em>again</em>, World!</div>' ); ?>
<div><?php _e( 'Hello <em>again</em>, World!' ); ?></div>

Na primeira linha do código acima, a inclusão da tag <div> no texto a traduzir é claramente desnecessária, mas faz todo o sentido deixar explícita para o tradutor a ênfase dada à palavra “again”.

Regra geral, tags que englobem a totalidade da string devem ser deixadas fora da tradução.

Tradução de JavaScript

A biblioteca gettext usada pelo WordPress contempla apenas a tradução de ficheiros PHP. Na eventualidade de ser necessário traduzir ficheiros JavaScript, o WordPress oferece a função wp_localize_script(). Infelizmente, não é uma solução que preze a elegância dado que injecta código JavaScript no cabeçalho das páginas, violando os princípios do JavaScript não obstrutivo.

Eis um exemplo de utilização:

<?php
// O script a traduzir deve ser incluído antes de chamar wp_localize_script():
wp_enqueue_script( 'my_script_handle' );

wp_localize_script(
    'my_script_handle',
    'MyTranslationObject',
    array(
        'greeting' => __( 'Hello, World!' ),
    )
);
?>

wp_localize_script() recebe o nome identificativo do script a traduzir (previamente registado e incluído na página), o nome do objecto JavaScript que irá conter o texto traduzido e um array associativo com uma correspondência entre chaves e texto traduzido com a função __().

A diferença é que, aqui, as strings propriamente ditas não podem ocorrer no JavaScript, ou não serão traduzidas. O script deve antes referir-se ao objecto de tradução declarado (neste caso, MyTranslationObject) e ao nome da variável que corresponde à string. Assim:

alert( 'Hello, World!' ); // Antes
alert( MyTranslationObject.greeting ); // Depois

O processo de tradução

Embora possamos ter todo o nosso projecto preparado para internacionalização, a tradução do texto não é automática. Aqui intervêm os tradutores que, sem acesso ao código e sem conhecimentos técnicos profundos, devem verter as strings do projecto para os vários idiomas de destino.

Antes de mais, será preciso compilar as strings do projecto através de um comando como o xgettext, embora a Automattic ofereça ao público ferramentas mais adequadas ao WordPress no seu repositório SVN.[1] Usando estes últimos, em particular o script makepot.php, as strings de um plugin podem ser obtidas com um simples:

php makepot.php wp-plugin <directoria do plugin>

(No caso de um tema, devemos substituir “wp-plugin” na linha acima por “wp-theme”.)

Independentemente da ferramenta usada, o que todas fazem é percorrer os ficheiros do projecto e identificar o conteúdo textual associado a funções de tradução. O fruto deste processo de recolha é um ficheiro modelo com a extensão POT (Portable Object Template), que deve ser entregue aos tradutores da solução para que estes possam gerar as versões localizadas.

A tradução é feita manualmente[2] usando uma aplicação como o Poedit, compatível com os principais sistemas operativos, ou através de uma solução baseada na web como o GlotPress.

Este processo implica pegar no POT gerado anteriormente para criar ficheiros localizáveis com a extensão PO (Portable Object, editável) e MO (Machine Object, versão compilada para utilização pelo gettext). Uma vez traduzidos, estes novos ficheiros devem ser enviados de volta à equipa de desenvolvimento para inclusão no projecto.

Quando o texto de um projecto sofre alterações, basta voltar a gerar o POT como de início, e importá-lo no software de tradução de modo a que as novidades sejam propagadas para os ficheiros PO e MO de cada idioma.

Referências

Para informações adicionais sobre internacionalização em WordPress, recomendamos as seguintes leituras e recursos:

• “i18n for Developers” (WordPress Codex)
• “Lost in Translation”, por Zé Fontainhas
• “Internationalization: You’re probably doing it wrong”, por Samuel “Otto” Wood
• WP Polyglots

Ça va? Para quaisquer dúvidas ou sugestões, a nossa página no Facebook está, como sempre, aberta à participação dos leitores.

In my case, the bug hit me a few months ago, when I started reading Gamestorming. My goal was simple: to learn new dynamics in order to develop business and teams. Yet, somehow, I was stuck on visual and entered in what I like to call visual mode. And now, I’m hooked!

Don’t get me wrong: I’m not an expert in this field! I’m just having fun learning more about it and I want to share my personal experience on how this process started working for me.

I hope I can inspire some of you, if only just a bit, to start looking at the world in a different and funny way!

1. Start Sketching… not drawing

Sketch everything you want, even if it looks ridiculous. Were you successful in conveying the message? Great! You did it! Not really? Well, keep trying! But don’t try to achieve artistic perfection except, of course, if you are an accomplished artist. You won’t succeed and you’ll feel frustrated. In order to sketch you don’t need to know how to draw. Trust me. I can’t REALLY draw, dogs look like crocodiles!

2. Transforme the way you work.

I got rid of my to-do list. But wait… I still have a bunch of things I need to do. I’ve just transformed it in something more appealing and easy to ready. It works for me.

It’s a small white cardboard with the things I need to do or think about, in different colored and shaped post-it notes.

OTB means Outside the Box.

3. Get up and head to the whiteboard.

Don’t just sit there craving for it. Get up and go. Sketch, write, underline, draw a box, or whatever comes through your mind. Expose yourself.

4. Pratice. Pratice. Pratice.

Your cell phone drawings will look less and less like bricks.

5. Embrace digital.

iPad, tablets. I use Noteshelf, Showme, Inkflow. And a Bamboo pen.

6. …but don’t forget paper!

Paper is visual mode’s best friend. I use a Micron Sakura 0.45mm black pen and a few Tombow ABT Dual Brush colour pens, for my thinking process. What am I talking about? Well, for instance, when I go to a meeting, I draw some sketches, write notes, etc. For this, I will only use a black pen. Afterwards, I will colour my notes during my information workflow recap. It’s a way to absorb or consolidate the whole data.

Forget pencils. Remember: the goal is not to draw perfectly.

7. Transform the meetings you’re in.

Whiteboards, post its, markers, colour papers, whatever. Lose the laptop.

8. Start right away.

You don’t need to read 10 books, 20 articles, or watch 5 films to get started. You just need to be inspired. Start small and at your own pace. Grab a pen, some paper and go for it!

9. Watch out for the overwhelmed syndrome.

This is a tricky one, at least for me! When I start reading or learning about something I really like, I tend to embark in a long arduous search for books, articles and videos that cover the subject. What happens when I do that? I get so overloaded with information that, at some point, I don’t really know where to start or even what to do!

Don’t overexplore it. Go with the flow. You have to have your own rhythm.

10. Have fun!

Indeed. If you’re not having fun, forget it! Focus on what you really love and what brings you joy.

Remember, this is a way of thinking. It will take time. However, when you least expect it you’ll start thinking visually. And this is all you need to do in order to enter the visual mode and becoming addicted. I certainly did!

Wanna go visual?

Todavia, os desenvolvimentos foram apresentados no contexto da alteração de um tema, escrevendo código no seu ficheiro functions.php. Embora haja várias situações em que esta utilização é perfeitamente legítima e até ideal, a lógica da plataforma deve estar tão separada quanto possível das camadas de apresentação. Pretendemos que o código desenvolvido seja independente do tema, que possa ser reutilizado por outros e que o site não perca funcionalidade se por acaso o tema mudar.

O primeiro plugin

Felizmente, é muito fácil migrar código existente no tema para um plugin. Basta criar uma pasta na directoria wp-content/plugins/ e, lá dentro, um ficheiro PHP contendo um cabeçalho especial. O código, tal como surge no functions.php, pode ser movido directamente para este ficheiro sem que nada deixe de funcionar (desde que se lembrem de activar o novo plugin na área de administração!)

Por exemplo, colocando o seguinte num novo ficheiro wp-content/plugins/primeiro-plugin/primeiro-plugin.php:

<?php
/*
Plugin Name: O meu primeiro plugin
Description: Este é o meu primeiro plugin.
Version: 1.0
Author: O meu nome
Author URI: http://log.pt/
*/

// Aqui vai o código do meu plugin...

?>

O resultado pode ser consultado na página de administração de plugins.

O plugin na página de administração do WordPress.

Plugin de favoritos

Naturalmente, o nosso primeiro plugin não fará nada se não contiver código. Para consolidar o que aprendemos nos artigos anteriores, bem como introduzir alguns conceitos novos, como o carregamento de ficheiros JavaScript e CSS, ou a invocação de pedidos AJAX, vamos explicar como desenvolver um plugin que permita aos visitantes assinalar artigos e páginas do site como favoritas.

Para este plugin, iremos desenvolver as seguintes componentes:

• Um shortcode com um botão para adicionar ou retirar uma página dos favoritos;
• Um shortcode que permita mostrar, em qualquer página, todos os favoritos do visitante;
• Uma widget que permita mostrar um número configurável de páginas favoritas.

A primeira pedra

Lancemos pois as fundações sobre as quais o nosso plugin será construído. Pegando no exemplo anterior, adicionamos o seguinte código:

<?php
/*
Plugin Name: My Favorites
Plugin URI: http://log.pt/
Description: My favorite posts plugin.
Version: 1.0
Author: log.OSCON
Author URI: http://log.pt/
*/

define( 'MY_FAVORITES_VERSION', '1.0' );

if (!class_exists( 'MyFavoritesPlugin' )) :

class MyFavoritesPlugin {

    public static function activate ()
    {
        // Método para activação do plugin
    }

    public static function init ()
    {
        // Método para inicialização do plugin

        load_plugin_textdomain( 'my-favorites', false, dirname( plugin_basename( __FILE__ ) ) . '/languages' );
    }
}

endif;

if (class_exists( 'MyFavoritesPlugin' ))
{
    /* Register hooks */
    register_activation_hook( __FILE__, array( 'MyFavoritesPlugin', 'activate' ) );

    /* Init actions */
    add_action( 'init', array( 'MyFavoritesPlugin', 'init' ) );
}

Aqui apenas registarmos dois hooks, o novo register_activation_hook(), para nos permitir executar código aquando da activação do plugin, e o já conhecido add_action() que associará o nosso método MyFavoritesPlugin::init() ao passo de inicialização da plataforma.

De notar que não estamos a usar funções como fizemos até agora, mas sim uma classe com vários métodos estáticos. Fazemos isto por causa de uma limitação histórica da linguagem PHP, que até há bem pouco tempo não suportava namespaces, fazendo com que todas as funções existissem no mesmo escopo global. Definir novas funções num plugin é, por isso, um exercício arriscado, uma vez que nomes demasiado comuns podem facilmente colidir com as funções já definidas noutros pontos da plataforma, ocasionando erros no servidor.

A função add_action() (e outras semelhantes) que aceitavam uma string com o nome da função de callback aceitam também um array com a estrutura array( '<nome ou instância da classe>', '<nome do método>' ).

No método de inicialização estamos já a fazer uma chamada a load_plugin_textdomain(). Esta função declara o domínio de tradução “my-favorites” para as várias strings do plugin. Não nos iremos demorar aqui[1], excepto para dizer que é boa prática deixar o nosso código preparado para internacionalização.

JavaScript e CSS

Tanto temas como plugins podem injectar o seu próprio JavaScript e estilos CSS nas páginas geradas pelo WordPress. Tal é feito com recurso aos pares de funções wp_register_script()/wp_register_script() e wp_register_style()/wp_register_style(). Acrescentemos o seguinte código ao final do nosso método MyFavoritesPlugin::init():

wp_register_style(
    'my-favorites',
    plugins_url( 'css/default.css', __FILE__ ),
    false,
    MY_FAVORITES_VERSION,
    'screen'
);

wp_enqueue_style( 'my-favorites' );

wp_register_script(
    'my-favorites',
    plugins_url( 'js/default.js', __FILE__ ),
    array( 'jquery' ),
    MY_FAVORITES_VERSION,
    false
);

wp_enqueue_script( 'jquery' );
wp_enqueue_script( 'my-favorites' );

wp_register_script() indica ao WordPress que existe um novo script JavaScript que pode ser incluídos nas páginas usando wp_enqueue_script(). Este script deve ter um nome e um ficheiro (os dois primeiros parâmetros da função). Podemos opcionalmente indicar dependências (no nosso caso, o ficheiro JavaScript depende do jQuery, que vem incluído na plataforma, pelo que não é preciso declará-lo). O quarto parâmetro indica a versão do script, que não sendo estritamente necessária, é útil para evitar que a cache dos browsers carreguem uma versão antiga do ficheiro quando este muda. Por fim, podemos indicar através de um valor booleano se o script é carregado no cabeçalho (false) ou no rodapé (true) da página.

No fim, incluímos tanto o jQuery como o nosso script na página gerada pelo WordPress usando wp_enqueue_script().

O processo para os estilos é em tudo semelhante ao anterior, a diferença é que o último parâmetro indica, não a área de carregamento, mas o tipo de CSS a incluir (por exemplo, “screen” ou “print”).

Em ambos os casos, usamos a função do WordPress plugins_url() para nos indicar o URL dos ficheiros.

Os ficheiros JavaScript e CSS usados neste projecto são fornecidos abaixo no arquivo ZIP com o código do plugin. Estes controlam a apresentação dos botões e listas de favoritos, bem como a funcionalidade AJAX que serve para assinalar determinada página como favorita.

Favoritos do utilizador

Concentremo-nos agora nos métodos para escrita e obtenção da lista de favoritos de um dado utilizador. Há aqui um cuidado especial a ter porque este utilizador pode ou não estar autenticado, e temos de garantir um mínimo de persistência dos dados em qualquer dos casos.

Para um utilizador não-autenticado, não há outra forma de guardar a lista de favoritos sem ser em cookie. Aos outros, contudo, podemos associar dados através de um conjunto de funções oferecidas pelo WordPress, entre as quais se contam get_user_meta() e update_user_meta().

Começando pelo nosso método de guardar a lista de favoritos do utilizador que recebe um nome identificativo da lista (neste projecto iremos usar apenas “my-favorites”), o identificador do utilizador e a lista com os IDs dos artigos e páginas favoritas, teremos:

private static function set_user_post_list ( $listname, $user_id = null, $list = array() ) {
    if (!$list) $list = array();
    /* Garantir que os identificadores são todos numéricos: */
    $list = array_map( 'intval', $list );

    if ($user_id)
    {
        /* O utilizador está autenticado, guardar lista em base de dados: */
        update_user_meta( $user_id, $listname, $list );
        /* Limpar a cache do utilizador para garantir a actualidade dos dados apresentados: */
        wp_cache_delete( $user_id, 'users' );    
        wp_cache_delete( $user_id, 'usermeta' );
    }
    else
    {
        /* O utilizador não está autenticado, guardar lista em cookie: */
        setcookie( $listname, serialize( $list ), time() + 365 * 24 * 60 * 60, COOKIEPATH, COOKIE_DOMAIN, false );
    }
}

Codificamos agora a operação inversa, de obter uma lista de artigos com base no seu nome e, opcionalmente, no identificador do utilizador:

private static function get_user_post_list ( $listname, $user_id = null ) {
    $list = ($user_id) ? get_user_meta( $user_id, $listname, true )
                       : unserialize( $_COOKIE[$listname] );
    if (!$list) $list = array();
    return array_map( 'intval', $list );
}

Por fim, vamos desenvolver um método que obtenha a lista de favoritos do visitante actual e imprima o HTML necessário à sua apresentação. Este método pode ser invocado directamente, mas também será útil para as funções de shortcode e AJAX que iremos desenvolver de seguida:

public static function favorite_list ( $atts ) {
    global $user_ID;

    $atts = shortcode_atts( array(
        'paged'          => 1,
        'posts_per_page' => 10,
        'order'          => 'ASC',
        'orderby'        => 'title',
    ), $atts );

    extract( $atts );

    // Validação básica:
    $paged = (int) $paged;
    $posts_per_page = (int) $posts_per_page;

    $favorites = array_map( 'intval', self::get_user_post_list( 'my_favorites', $user_ID ) );

    if (empty( $favorites ))
    {
        _e( 'You have no favorite posts.', 'my-favorites' );
    }
    else
    {
        $query = new WP_Query( array(
            'post_type'      => get_post_types( array( 'public' => true ) ),
            'post__in'       => $favorites,
            'paged'          => $paged,
            'posts_per_page' => $posts_per_page,
            'post_status'    => 'publish',
            'order'          => $order,
            'orderby'        => $orderby,
        ) );

        if ($query->have_posts()) : ?>          
            <ul class="fav-list">
            <?php while ($query->have_posts()) : $query->the_post(); ?>
                <li>
                    <?php my_favorite_toggle_button(); ?>
                    <a href="<?php the_permalink() ?>" rel="bookmark" class="favorite-link" title="<?php the_title(); ?>"><?php the_title(); ?></a>
                </li>
            <?php endwhile; ?>
            </ul>
        <?php endif;
    }
}

Inclusão de código PHP

O código PHP de um plugin não tem de estar todo no mesmo ficheiro. Para não complicar a leitura e a localização de código, vamos incluir uma série de ficheiros adicionais com uma ajuda da função plugin_dir_path() para obter o caminho.

if (class_exists( 'MyFavoritesPlugin' ))
{
    /* Register hooks */
    register_activation_hook( __FILE__, array( 'MyFavoritesPlugin', 'activate' ) );

    /* Init actions */
    add_action( 'init', array( 'MyFavoritesPlugin', 'init' ) );

    require_once( plugin_dir_path( __FILE__ ) . 'includes/functions.php' );
    require_once( plugin_dir_path( __FILE__ ) . 'includes/shortcodes.php' );
    require_once( plugin_dir_path( __FILE__ ) . 'includes/widgets.php' );
}

Funções

Feito isto, podemos agora criar um ficheiro em includes/functions.php contendo a declaração de funções para imprimir o botão de favoritos e a lista de artigos.

    <?php /* File: includes/functions.php */

function my_favorite_toggle_button ( $post_id = null, $atts = array() )
{
    global $user_ID;

    $atts = extract( shortcode_atts( array(
        'ajax'           => false,
    ), $atts ) );

    if (!isset( $post_id )) {
        $post_id = get_the_ID();
    }

    if (!$post_id) {
        error_log( __FUNCTION__ . ' must be called within a post loop.' );
        return;
    }

    $favorites  = MyFavoritesPlugin::get_user_post_list( 'my_favorites', $user_ID );

    $tooltip    = (in_array( $post_id, $favorites ))
                    ? __( 'Remove from favorites', 'my-favorites' )
                    : __( 'Add to favorites', 'my-favorites' );

    $class      = (in_array( $post_id, $favorites )) ? ' favorite-post-on' : ' favorite-post-off';

    if (!is_user_logged_in())
    {
        $class  .= ' guest';
    }

    if (!$ajax && (!is_user_logged_in() || defined( WP_CACHE ) && WP_CACHE))
    {
        // Update button following AJAX call:
        $class  .= ' cache-workaround';
    }

    $class .= " size-24";

    echo '<div class="my-favorite">';

    echo '<a href="#" class="favorite-post-toggle ' . $class . ' my-favorite-post-' . $post_id . '"'
        . ' id="my-favorite-post-' . $post_id . '" title="' . esc_attr( $tooltip ) . '">';

    echo '<span class="favorite-post-on-button">';
    echo '<span class="label">';
    _e( 'Remove from favorites', 'my-favorites' );
    echo '</span>';
    echo '</span>';

    echo '<span class="favorite-post-off-button">';
    echo '<span class="label">';
    _e( 'Add to favorites', 'my-favorites' );
    echo '</span>';
    echo '</span>';

    echo '</a>';

    echo '</div>';
}

function my_favorite_list ( $atts ) {
    $atts = shortcode_atts( array(
        'paged'          => 1,
        'posts_per_page' => 10,
        'order'          => 'ASC',
        'orderby'        => 'post__in',
        'ajax'           => false,
    ), $atts );

    $class      = "";
    $data_attr  = "";

    if (!is_user_logged_in() || (defined( WP_CACHE ) && WP_CACHE)) {
        $class .= " cache-workaround";
    }

    foreach ($atts as $k => $v) {
        $data_attr .= ' data-' . preg_replace( '/[^A-Za-z0-9]/', '-', $k ) . '="' . esc_attr( $v ) . '"' ;
    }

    echo '<div class="my-favorite-post-list' . $class . '"' . $data_attr . '>';

    if (!is_user_logged_in() || (defined( WP_CACHE ) && WP_CACHE)) {
        // Insert AJAX list placeholder:
        _e( 'Fetching favorites...', 'my-favorites' );
    } else {
        // No cache, so print list directly:
        MyFavoritesPlugin::favorite_list( $atts );
    }

    echo '</div>';
}

?>

Apesar das referências a AJAX no código, ainda não estamos a fazer nada com resultados práticos. Queremos apenas definir um conjunto de classes HTML que irão servir de fundação para a posterior associação de eventos e actualização de conteúdos através de JavaScript.

Estas referências a AJAX aparecem associadas a verificações do estado da cache da plataforma. Isto porque queremos evitar que a apresentação das listas de favoritos de um determinado utilizador fique armazenada em cache pelo WordPress, evitando também que os dados sejam indevidamente apresentados a terceiros. Ao apresentar estes dados preenchidos em resultado de um pedido AJAX, estamos a garantir que a cache do sistema não os afecta (o que não significa que os pedidos AJAX não possam ficar guardados em cache, se necessário!).

Shortcodes

Dado que vamos reaproveitar o código das funções que acabámos de definir, o registo dos shortcodes torna-se muito mais simplificado:

<?php /* File: includes/shortcodes.php */

function my_favorite_toggle_button_shortcode ( $atts ) {
    extract( shortcode_atts( array(
        'post_id' => get_the_ID(),
    ), $atts ) );

    ob_start();
    my_favorite_toggle_button( $post_id );
    $output = ob_get_clean();

    return $output;
}

add_shortcode( 'my_favorite_button', 'my_favorite_toggle_button_shortcode' );

function my_favorite_list_shortcode ( $atts ) {
    ob_start();
    my_favorite_list( $atts );
    $output = ob_get_clean();

    return $output;
}

add_shortcode( 'my_favorite_list', 'my_favorite_list_shortcode' );

?>

…ficando assim com os shortcodes [my_favorite_button], que acrescenta um botão à página, e [my_favorite_list], para exibir a lista de favoritos do utilizador.

Widgets

O registo da widget de favoritos em nada varia do que aprendemos no artigo anterior desta série:

 <?php /* File: includes/widgets.php */

class MyFavorite_Posts_Widget extends WP_Widget {

    public function MyFavorite_Posts_Widget () {
        parent::__construct(
            'my_favorite_posts', // Identificador
            'My Favorite Posts', // Nome
            array( 'description' => __( 'Displays a list of posts favorited by the user.' ), ) // Argumentos
        );
    }

    public function form ( $instance ) {
        $title    = isset( $instance['title'] )    ? esc_attr( $instance['title'] )  : '';
        $number   = isset( $instance['number'] )   ? absint( $instance['number'] )   : 5;
        ?>
        <p>
            <label for="<?php echo $this->get_field_id( 'title' ); ?>"><?php _e( 'Title:' ); ?></label> 
            <input class="widefat" id="<?php echo $this->get_field_id( 'title' ); ?>" name="<?php echo $this->get_field_name( 'title' ); ?>" type="text" value="<?php echo esc_attr( $title ); ?>" />
        </p>
        <p>
            <label for="<?php echo $this->get_field_id( 'title' ); ?>"><?php _e( 'Number of posts to show:' ); ?></label> 
            <input id="<?php echo $this->get_field_id( 'number' ); ?>" name="<?php echo $this->get_field_name( 'number' ); ?>" type="text" value="<?php echo esc_attr( $number ); ?>" size="3" />
        </p>
        <?php 
    }

    public function update ( $new_instance, $old_instance ) {
        $instance = (array) $old_instance;

        $instance['title']    = strip_tags( $new_instance['title'] );
        $instance['number']   = absint( $new_instance['number'] );

        return $instance;
    }

    public function widget ( $args, $instance ) {
        extract( $args );

        $number   = absint( $instance['number'] );
        $title    = apply_filters( 'widget_title', empty( $instance['title'] )
                  ? __( 'Favorite Posts', 'my-favorites' )
                  : $instance['title'], $instance, $this->id_base );

        if (!$number)
            $number = 5;

        ob_start();
        my_favorite_list( array( 'posts_per_page' => $number ) );
        $output = ob_get_clean();

        if (!empty( $output )) {
            echo $before_widget;
            if ($title)
                echo $before_title . $title . $after_title;
            echo $output;
            echo $after_widget;
        }
    }
}

add_action( 'widgets_init', create_function( '', 'register_widget( "MyFavorite_Posts_Widget" );' ) );
?>

Caching e AJAX

Com o código anterior, temos um plugin quase funcional, faltando um elemento crucial: apesar de dispor de um botão, o utilizador não consegue ainda adicionar ou retirar um artigo da sua lista de favoritos. O botão irá depender de uma invocação AJAX para informar o WordPress da acção sem obrigar ao recarregamento da página.

Para isso já temos, no JavaScript fornecido com este artigo,

jQuery.post(
    FavoritesAjax.ajaxurl, // URL do WordPress
    {
        action:     'my_toggle_favorite', // Acção a executar
        post_id:    post_id
    },
    function (response) {
        if (response) {
            // Processamento da resposta e actualização do estado do botão
        }
    },
    'json'
);

Há aqui dois elementos a ter em atenção.

O primeiro é o objecto FavoritesAjax que contém o URL do pedido. Este pode ser registado no final do nosso método MyFavoritesPlugin::init, logo a seguir ao registo de scripts com o WordPress, usando a função wp_localize_script().

Esta função serve para traduzir strings que ocorram num script, mas também para injectar outros valores JavaScript na página. Neste caso, queremos que o JavaScript conheça o URL usado pelo WordPress para todos os pedidos AJAX, presente em wp-admin/admin_ajax.php (apesar da localização do ficheiro, este não se limita ao uso por administradores):

wp_localize_script(
    'my-favorites',
    'FavoritesAjax',
    array( 'ajaxurl' => admin_url( 'admin-ajax.php' ) )
);

O segundo elemento é o my_toggle_favorite que é passado como valor do parâmetro action do pedido AJAX. É este que vai permitir ao WordPress relacionar o pedido com uma acção específica previamente registada na plataforma, no passo de inicialização do nosso plugin:

add_action( 'wp_ajax_my_toggle_favorite'        , array( 'MyFavoritesPlugin', 'ajax_toggle_favorite' ) );
add_action( 'wp_ajax_nopriv_my_toggle_favorite' , array( 'MyFavoritesPlugin', 'ajax_toggle_favorite' ) );

A função add_action() é já nossa conhecida, mas temos uma novidade na medida em que esta suporta dois tipos especiais para processamento de pedidos AJAX determinados pelo prefixo no nome da acção: wp_ajax_ (para utilizadores autenticados) e wp_ajax_nopriv_ (para utilizadores sem previlégios). O restante nome da acção é o valor do parâmetro action passado no pedido AJAX.

Aqui, definimos o callback da acção como MyFavoritesPlugin::ajax_toggle_favorite(). Vamos pois adicioná-lo à classe do plugin:

public static function ajax_toggle_favorite ()
{
    global $user_ID;

    $favorites  = self::get_user_post_list( 'my_favorites', $user_ID );

    $output     = false;
    $post_id    = (int) $_POST['post_id'];
    $key        = array_search( $post_id, $favorites );

    if ($key === false or !isset( $key ))
    {
        // Add to favorites:
        array_unshift( $favorites, $post_id );
        $favorites = array_unique( $favorites );
        $output = $post_id;
    }
    else
    {
        // Remove from favorites:
        unset( $favorites[$key] ); 
        $output = 0;
    }

    self::set_user_post_list( 'my_favorites', $user_ID, $favorites );

    header( 'Content-Type: text/x-json' );
    echo json_encode( $output );
    die();
}

Com isto, podemos finalmente observar o plugin em acção.

Botão de favoritos no artigo e widget na barra lateral.

Se a plataforma estiver a utilizar uma solução de caching como o WP Super Cache ou o W3 Total Cache, logo constatamos que apenas funciona convenientemente quando o utilizador se encontra autenticado. Para os restantes casos, a cache tende a guardar as páginas apresentadas, recusando-se a actualizar a lista de favoritos, pelo que precisamos de um método para contornar este comportamento. Aqui voltamos a recorrer ao AJAX para que, em circunstâncias em que a cache esteja activa, possamos continuar a obter conteúdos “frescos”.

No nosso método de inicialização, acrescentamos as seguintes linhas:

add_action( 'wp_ajax_my_favorite_list'          , array( 'MyFavoritesPlugin', 'ajax_favorite_list' ) );
add_action( 'wp_ajax_nopriv_my_favorite_list'   , array( 'MyFavoritesPlugin', 'ajax_favorite_list' ) );

E, na classe do plugin, definimos o método a invocar para as novas acções:

public static function ajax_favorite_list ()
{
    $paged          = (int) $_POST['paged'];
    $posts_per_page = (int) $_POST['posts_per_page'];
    $order          = $_POST['order'];
    $orderby        = $_POST['orderby'];

    $atts = array(
        'paged'             => $paged,
        'posts_per_page'    => $posts_per_page,
        'order'             => $order,
        'orderby'           => $orderby,
        'ajax'              => true,
    );

    header( 'Content-Type: text/html' );
    self::favorite_list( $atts );
    die();
}

O princípio é semelhante ao que já vimos para a acção my_toggle_favorite, com a diferença que o pedido AJAX irá retornar todo o HTML da lista de favoritos para ser injectado na página por JavaScript, assim:

jQuery.post(
    FavoritesAjax.ajaxurl,
    {
        action:         'my_favorite_list',
        paged:          paged,
        posts_per_page: posts_per_page,
        order:          order,
        orderby:        orderby
    },
    function (response) {
        jQuery(el).html(response);
    },
    'html'
);

Código do plugin

Por uma questão de brevidade, há uma série de dinâmicas que não se encontram aqui descritas, como a actualização dos eventos associados a certas hiperligações numa lista de favoritos injectada via AJAX, ou a capacidade de mostrar a lista dos favoritos pela ordem em que foram adicionados. Recomendamos a consulta do código fonte, disponível abaixo e pronto para ser utilizado em qualquer site WordPress.

• Descarregar My Favorites 1.0 (ZIP, 31 KB)

No próximo artigo desta série, continuaremos a desenvolver o plugin de favoritos para incluir páginas de configuração no painel de administração do WordPress. Como sempre, estamos disponíveis para dar resposta às questões e sugestões dos nossos leitores na nossa página no Facebook.

Um dos primeiros passos que se deve adotar para reduzir a taxa de abandono é a implementação de um processo de compra de apenas uma página, embora existam outros fatores que podem desmotivar e afastar os utilizadores do processo de compra final.

O processo deve ser linear

Criar um vasto número de passos a efetuar ou mesmo criar passos dentro de passos, confunde e intimida os utilizadores, uma vez que quebra o modelo mental do processo de compra. Isto é crítico uma vez que, no processo mental dos utilizadores, o processo de compra deve ser linear e sequencial.

Um exemplo desta não linearidade é pedir ao utilizador dados da morada de envio numa nova página e depois fazer um redireccionamento para o passo anterior. Ver a mesma página duas vezes, faz com que a maioria dos utilizadores pense que ocorreu um erro no processo, uma vez que é este o comportamento no momento da validação de formulários.

Evitar termos como “Continuar”

Usar termos como “Continuar” são ambíguos e tendem a confundir os utilizadores.

Dependendo do momento, um botão “Continuar” no processo de compra pode significar uma de duas coisas:

1. Continuar a comprar, ou seja, o utilizador pode continuar a procurar mais produtos;
2. Continuar para o processo de pagamento, ou seja, quando o utilizador já tem todos os produtos e quer pagar.

Outro exemplo é o botão “Voltar”. Quererá esta ação significar voltar à página anterior ou voltar à página dos resultados?

Estes são exemplos de termos que podem ter diferentes interpretações dependendo do contexto (qual a página onde o utilizador se encontra) e também da interpretação dos utilizadores. A solução neste caso é substituir estes termos ambíguos, por palavras que não deixam dúvidas sobre a ação que está implícita, como “Efetuar Pagamento” ou “Continuar a Comprar”.

Reforçar visualmente todos os campos sensíveis na página de pagamento

O momento da introdução dos dados de pagamento é sempre o momento mais desconfortável para os utilizadores. Principalmente se o pagamento for via cartão de crédito e se a informação relativa aos dados do cartão não parecer segura. Se assim for, os utilizadores vão hesitar em finalizar a compra.

Exemplo de informação clara e destacada sobre o método de pagamento e segurança

Colocar na página ícones e texto relativos à segurança do processo, levam a que a página seja percecionada como sendo segura, enquanto que as páginas que não contemplem esses elementos inspiram menos confiança.

Tecnicamente não existem diferenças entre estes dois tipos de página. No entanto, os utilizadores não sabem como funciona um site e a única coisa que sabem é o que o seu instinto lhes diz.

Adicionar pistas visuais ao design (cor de fundo, um contorno e ícones relativos a segurança) dos campos relativos aos dados do cartão de crédito, faz aumentar a percepção de segurança e assim, encaminhar os utilizadores para a finalização do processo de compra

Adicionar descrições aos campos dos formulários

Quando os campos dos formulários não contemplam descrições estes podem tornar-se ambíguos. Esta ausência de explicação potencia que alguns utilizadores não saibam que tipo de informação se está a ser pedida.

Estes problemas podem ser resolvidos adicionando pequenas descrições e exemplos junto às etiquetas.

Uma vez que nem todos os utilizadores precisam deste tipo de explicação, pode-se esconder a informação por detrás de um link “Saiba mais” ou reduzir o tamanho da fonte.

Esta sugestão é extensível para campos que em princípio, não levantam dúvidas, como o campo do Email. Pode aproveitar-se para informar ao utilizador o que irá ser feito com a informação. Muitos utilizadores podem querer saber o que irá ser feito com os endereços de email.

Não usar um botão de “Aplicar” no formulário

Os utilizadores desconhecem o significado que um botão “Aplicar” tem, para diferentes secções da página.

Em vez de usar o termo “Aplicar” dever-se-á usar termos mais específicos.

Em vez de usar o termo “Aplicar” devemos usar termos mais específicos

Usar esta terminologia em ações como a confirmação de um método de envio, pode fazer com que o botão nunca seja clicado, pois o utilizador pode confundi-lo com a ação de submeter o formulário.

Neste caso, quando o utilizador confunde o botão de “Aplicar” com o botão de submeter o formulário e ao efetuar a ação é redirecionado para a mesma página, a consequência é a frustação das suas expectativas sobre o passo seguinte da compra.

Aconselha-se também a redução da utilização de botões “Aplicar”, recorrendo neste caso ao AJAX para validação e atualização de um valor.

Usar apenas uma coluna para os campos do formulário

É muito difícil para os utilizadores relacionarem os campos em formulários quando estes estão distribuídos por duas colunas.

Normalmente podem acontecer dois tipo de erros:

1. Uma das colunas é ignorada ou não é relacionada com o formulário e o utilizador não preenche esses dados.
2. Campos não relacionados são preenchidos e submetidos, causando erros de validação.

Usar indicações de erro de forma evidente

A maioria dos utilizadores tem grandes dificuldades em encontrar e entender as mensagens de erro.

Quando um utilizador tem um problema no preenchimento de um formulário, a probabilidade de abandono do formulário aumenta significativamente.

As mensagens de erro devem ser colocadas junto dos campos que contêm erros ou corre-se o risco de estas serem ignoradas pelos utilizadores. Sem esta proximidade pode tornar-se difícil compreender as mensagens. Nestes casos, os utilizadores tendem não notar nada de errado com os campos, tentando submeter os formulários.

Se os utilizadores não compreenderem as mensagens de erro, não conseguirão resolver os problemas ou prosseguir para processo de compra. Nestes casos, o abandono é inevitável. É assim muito importante, empenhar bastante esforço para desenhar e comunicar eficazmente as mensagens de erro.

Um bom exemplo de como apresentar as mensagens de erro

Devemos assegurar que as mensagens de erro:

• Estão contextualizadas (não estão apenas no topo da página, mas também junto ao campo que contém o erro);
• São claras e concisas;
• Distinguem-se do resto do layout (grande contraste e o uso de setas ou outros elementos visuais).

Incluir sempre um mini-carrinho de compras

Normalmente os carrinhos de compras são apresentados de duas formas: um carrinho de compras completo e funcional na página e um “mini” carrinho de compras, normalmente localizado na barra lateral. A melhor prática é incluir os dois.

O site da Amazon disponibiliza sempre um mini-carrinho

Com o carrinho de compras completo, podemos incluir mais informação e opções. Por exemplo podemos mostrar informação acerca do produto, remover/editar produtos, montante das taxas e opções de envio.

Os mini-carrinhos mostram informação dentro de um área pequena que não provoca ruído com o restante layout da página.

Destacar os botões de pagamento e de adicionar

A distinção entre botões com ações distintas como pagar ou adicionar mais produtos é de extrema importância. Para tal, é aconselhável usar botões que se distingam claramente dos restantes elementos da página.

Esta falta de distinção pode fazer com que os utilizadores não encontrem os botões para finalizar a compra e assim, nunca finalizarem a comprar!

Usar tabelas para comparação de produtos

É boa prática utilizar uma estrutura em tabela quando desenhamos uma página do carrinho de compras. A página deve disponibilizar a informação de forma eficiente e sem quebras na leitura. Devem ser utilizadas fontes standard e evitar usar fundos complexos.

Devem-se sempre usar contornos para separar as várias células. A informação no carrinho de compras deve ser de fácil leitura e sem quaisquer elementos que possam distrair ou aumentar a complexidade.

Usar a imagem do produto na página do carrinho de compras ajuda também o utilizador a relacionar os produtos que está a comprar.

Evitar usar demasiados campos

Para os utilizadores o preenchimento de formulários é uma tarefa frustrante, principalmente quando obriga ao preenchimento de campos que não são essenciais para o processo da compra.

Assim, deve-se desenhar o processo de compra da maneira mais simples possível, para que os utilizadores considerem o processo conveniente, ou será quase certo que não irão realizar uma compra através do site.

Deve-se restringir o número de campos ao mínimo, agrupar campos que se assemelhem e providenciar cabeçalhos para cada uma das secções. O uso do espaço branco também ajuda a tornar o formulário mais apelativo e organizado.

Outras dicas que optimizam o processo de compras online

• Usar imagens dos produtos com qualidade;
• Usar botões de “Adicionar ao Carrinho” e “Finalizar Compra” grandes para poderem ser usados em dispositivos móveis;
• Evitar o uso de elementos flash que tornem o carregamento lento;
• Assegurar que se fornece toda a informação ao utilizador, como por exemplo, em que passo ele se encontra e quantos passos faltam para terminar o processo.

Exemplos de boas práticas de carrinhos de compras

Cafepress

• Possibilidade de guardar o estado do carrinho;
• Integração com o Paypal;
• Possibilidade de alterar a quantidade;
• Múltiplos métodos de envio.

Cafepress processo de compra

Nike Store

• Integração com Paypal;
• Envio grátis para compras acima de um determinado montante;
• Recomendações “Também pode gostar”;
• Múltiplos métodos de envio.

Processo de compra da Nike Store

Bose

• Acessórios recomendados;
• Opções de pagamento e utilização dos logos dos cartões;
• Opção de pagar depois “Bill me later”;
• Envio gratuito;
• Processo de compra bastante explícito (4 passos).

Processo de compra do site da Bose

No presente artigo, iremos abordar os elementos de conteúdo e navegação que povoam as sidebars de muitos sites WordPress, e aprenderemos a desenvolver uma nova widget de raíz.

Sidebars (ou áreas de widgets)

Figura 1: Sidebars no painel de administração.

As widgets do WordPress são agrupadas e apresentadas em sidebars, áreas pré-definidas nos modelos de cada tema que podem ser configuradas pelo utilizador no painel de administração da plataforma. Um tema pode suportar qualquer número de sidebars. A configuração é feita mediante uma interface drag and drop, bastando ao utilizador arrastar para a sidebar desejada as widgets que pretende aí incluir, podendo ordená-las como desejar.

É possível registar novas sidebars usando a função register_sidebar(), passando-lhe um array associativo de argumentos, tais como o seu nome, identificadores ou a “moldura” HTML pretendida. Por exemplo:

register_sidebar( array(
    'name' => 'Nova Sidebar',
    'id'   => 'nova-sidebar'
) );

Existem outros parâmetros que podem ser passados à função register_sidebar() para personalizar o HTML produzido. Recomendamos a leitura da documentação da função para todos os pormenores.

Convém salientar que este registo, só por si, não garante que a sidebar vai aparecer no tema. Para isso é preciso invocá-la no modelo ou template do tema onde se pretende que ela seja apresentada. Esta invocação é feita chamando a função dynamic_sidebar() com o nome ou identificador da sidebar criada. Para o caso acima, isto seria:

dynamic_sidebar( 'nova-sidebar' );

A sidebar em questão precisa de ter pelo menos uma widget activa para ficar visível.

A minha primeira widget

Introduzidos os conceitos básicos das sidebars, voltamo-nos para o desenvolvimento das widgets propriamente ditas.

Ao contrário dos hooks e shortcodes que conhecemos até aqui, as widgets não se definem à custa de funções mas sim com classes PHP que herdam da superclasse WP_Widget. Esta classe deve implementar o construtor da classe e três outros métodos importantes:

• form(): Método que imprime o formulário de configuração da widget no painel de administração;
• update(): Método que regista as opções da widget configuradas no painel de administração;
• widget(): Método que imprime o conteúdo da widget, tal como será apresentado ao visitante do site.

Assim uma nova widget respeita o seguinte esqueleto de código:

class Latest_Category_Posts_Widget extends WP_Widget {

    public function Latest_Category_Posts_Widget () {
        // Método constructor da widget
    }

    public function form ( $instance ) {
        // Formulário de configuração
    }

    public function update ( $new_instance, $old_instance ) {
        // Processamento da configuração da widget
    }

    public function widget ( $args, $instance ) {
        // Apresentação da widget
    }

}

Após declarar a classe que implementa a widget, é necessário registá-la com a função register_widget(), deste modo:

register_widget( 'Latest_Category_Posts_Widget' );

É, no entanto, mais correcto registar a widget através de um hook de acção, no passo reservado à inicialização de widgets. Convém por isso alterar a linha acima para:

add_action( 'widgets_init',
    create_function( '', 'register_widget( "Latest_Category_Posts_Widget" );' ) );

Na inicialização da classe, através do seu método construtor, podemos definir atributos básicos como o nome e descrição da nossa widget. Vamos, pois, redefinir o nosso construtor da seguinte forma:

public function Latest_Category_Posts_Widget () {
    parent::__construct(
        'recent_category_posts', // Identificador
        'Recent Category Posts', // Nome
        array( 'description' => __( 'Latest posts in a category.' ), ) // Argumentos
    );
}

Figura 2: A primeira widget à espera de ser incluída.

Figura 3: Formulário de configuração em branco.

O resultado destas linhas é o apresentado na screenshot acima. No entanto, ao arrastar a widget para uma das sidebars do WordPress, constatamos que está vazia. O mesmo se passa na face pública do site. Trataremos agora de remediar essa situação, apresentando primeiro aos administradores da plataforma um formulário que permita configurar a widget, e de seguida o HTML apresentado aos visitantes com base nas opções seleccionadas.

Formulário de configuração

Pretendemos desenvolver uma widget que mostre um número determinado de artigos de uma categoria escolhida pelo administrador. Precisamos de pelo menos dois campos para isto: um onde o administrador selecciona a categoria, e outro para indicar o número de artigos a apresentar. Incluiremos também um campo de texto para o título da widget.

A dropdown para selecção da categoria será feita à custa da função [wp_dropdown_categories()][WPCodex:wp_dropdown_categories], o que nos poupa algum trabalho de construção da interface. O método que desenha o formulário toma portanto este aspecto:

public function form ( $instance ) {
    $title    = isset( $instance['title'] )    ? esc_attr( $instance['title'] )  : '';
    $category = isset( $instance['category'] ) ? absint( $instance['category'] ) : 0;
    $number   = isset( $instance['number'] )   ? absint( $instance['number'] )   : 5;
    ?>

<label for="<?php echo $this->get_field_id( 'title' ); ?>"><?php _e( 'Title:' ); ?></label>
        <input id="<?php echo $this->get_field_id( 'title' ); ?>" class="widefat" type="text" name="<?php echo $this->get_field_name( 'title' ); ?>" value="<?php echo esc_attr( $title ); ?>" />

        <?php wp_dropdown_categories( array(
            'show_option_all' => __( 'All' ),
            'orderby'         => 'name',
            'hide_empty'      => 0,
            'hierarchical'    => 1,
            'selected'        => $category,
            'id'              => $this->get_field_id( 'category' ),
            'name'            => $this->get_field_name( 'category' ),
            'class'           => 'widefat',
        ) ); ?>

<label for="<?php echo $this->get_field_id( 'title' ); ?>"><?php _e( 'Number of posts to show:' ); ?></label>
        <input id="<?php echo $this->get_field_id( 'number' ); ?>" type="text" name="<?php echo $this->get_field_name( 'number' ); ?>" value="<?php echo esc_attr( $number ); ?>" size="3" />

    <?php
}

Figura 4: Formulário de configuração.

Refrescando a página de administração de widgets, podemos constatar que as coisas têm melhor aspecto. Contudo, os valores introduzidos no formulário ainda não ficam guardados, é preciso agora definir o método update(). O processo é tão simples quanto definir as chaves de um array associativo a partir de um outro array com os dados de entrada:

public function update ( $new_instance, $old_instance ) {
    $instance = (array) $old_instance;

    $instance['title']    = strip_tags( $new_instance['title'] );
    $instance['category'] = absint( $new_instance['category'] );
    $instance['number']   = absint( $new_instance['number'] );

    return $instance;
}

Apresentação da widget

O passo final da criação desta widget consiste em apresentar ao utilizador, numa sidebar, a nossa lista de n artigos dentro da categoria pretendida.

Munidos do identificador da categoria e do número de artigos a apresentar, podemos obter a lista com que iremos preencher a widget. O título da widget é opcional: se o utilizador não definiu um no formulário de configuração, este será preenchido com o texto “Recent posts in %s”, onde o token %s é substituído pelo nome da categoria escolhido.

A lista é obtida com o objecto WP_Query, indicando os parâmetros posts_per_page para o limite de artigos apresentados, cat para o identificador da categoria, post_status para garantir que apenas mostramos artigos publicados e ignore_sticky_posts para que não surjam artigos de destaque, apenas os mais recentes. no_found_rows indica que não precisamos de saber quantos artigos existem no site, interessa-nos apenas uma lista dos mais recentes. Também não é preciso indicar explicitamente que pretendemos uma ordenação cronológica inversa porque WP_Query assume essa preferência por omissão.

public function widget ( $args, $instance ) {
    extract( $args );

    $category = absint( $instance['category'] );
    $number   = absint( $instance['number'] );
    $title    = apply_filters( 'widget_title', empty( $instance['title'] )
              ? sprintf( __( 'Recent posts in %s' ), get_the_category_by_ID( $category ) )
              : $instance['title'], $instance, $this->id_base );

    if (!$number)
        $number = 5;

    $q = new WP_Query( array(
        'posts_per_page'        => $number,
        'cat'                   => $category,
        'no_found_rows'         => true,
        'post_status'           => 'publish',
        'ignore_sticky_posts'   => true
    ) );

    $out = '';

    while ($q->have_posts()) {
        $q->the_post();
$out .= '</pre>
<ul>
	<li>};

 if (!empty( $out )) {
 echo $before_widget;

 if ($title)
 echo $before_title . $title . $after_title;

echo '
<ul>' . $out . '</ul>
';

 echo $after_widget;
 }
}

Esta widget pode ainda ser melhorada. Por exemplo, a lista compilada pode ser armazenada em cache do WordPress para que a sua apresentação não pese tanto. No entanto, o resultado final deste exemplo ilustrativo já pode ser observado na sidebar do site.

Figura 5: Voilà!

Boas práticas

No capítulo das melhores práticas de desenvolvimento, recomendamos que os interessados em desenvolver novas widgets se baseiem no WordPress Widget Boilerplate de Tom McFarlin, um modelo de projecto que adianta algum trabalho ao mesmo tempo que procura incutir bons hábitos na codificação de widgets para a plataforma. Recomendamos ainda o artigo que inspirou o projecto, Writing Maintainable WordPress Widgets, pelo mesmo autor.

A consulta da documentação da API no Codex é, claro, fundamental.

No próximo artigo, explicaremos como integrar tudo o que aprendemos até agora num plugin WordPress. Até lá, aguardamos questões e sugestões dos nossos leitores na nossa página no Facebook.