Há duas semanas, passei sérios problemas com o WordPress, com o blog Papo de Buteco. Nunca tinha passado por uma situação parecida com essa, e por isso que tomar cuidado antes de agir.

Como verifiquei

Por otimizar o site, sempre estou verificando como as páginas do blog estão se comportando no Google. Busquei por site:papodebuteco.net para verificar todas as minhas páginas indexas no Google, e obtive o seguinte resultado:

Ao primeiro olhar, já observei as tags de título das páginas estavam totalmente diferentes, no mínimo estranho, não é? Comecei a estudar a situação, e conclui que neste caso, aconteceu uma espécie de Cloaking, que reproduzia a página normal para o usuário e outra página para o Google.

De primeira, achei que eram os plug-ins instalados no site que estavam fazendo isso, mas até que o Google me enviou a seguinte mensagem para o Web Master Tools do site:

Ao acessar o link indicado na mensagem, e realmente foi mostrada uma página com um conteúdo não relacionado ao blog.

Solucionando o problema

O que precisa ser feito é: Reinstalar o WordPress para atualizar seus arquivos.

No próprio painel do gerenciador, é possível fazer essa reinstalação, então nada de apagar todos os arquivos do FTP, enviar novamente e reintegrar com o banco de dados.

Em seu painel de adiminstração, procure no menu de navegação por Atualizações e siga como na imagem abaixo:

Depois disso, acessei a página que o Google indicou na mensagem e não tive mais problemas, a página foi carregou com seu conteúdo real.

Para confirmar, você pode tirar a “prova real” buscando como o Googlebot, que é uma ferramenta encontrada no Google Webmaster Tools.

Ao clicar em “Processando” e estiver lendo a página do jeito que deveria ler, com o seu código fonte real, pode ter certeza que o problema foi resolvido.

Conclusão

Não se sabe ao certo ainda como essa invasão se manifestou no blog, mas é bom ficar atento a qualquer tipo de propagação estranha relacionada a seu site. O tipo de invasão apresentado no artigo não é único, podem existir outros casos espalhados. A vulnerabilidade pode também está relacionada com o servidor onde o seu site está hospedado.

As páginas que não entraram no cache do Google depois que o problema foi solucionado, ainda se encontram com o mesmo conteúdo da invasão, se vocês procurarem, ainda acharam algumas páginas assim.

Apesar de tudo isso, não houve oscilação com o número de visitas do site, ele se mantéu estável. E o número de backlinks apontados para as páginas do blog cresceu, mas com um textos âncora sem relação ao conteúdo real do blog.

O Cloaking é considerada uma técnica de blackhat pelo Google, caso o problema não fosse solucionado a tempo, o blog poderia ser sofrer algum tipo de punição, veja mais em: http://support.google.com/webmasters/bin/answer.py?hl=pt-BR&answer=66355.

Se o seu site ainda não é integrado ao Google Web Master Tools, acesse agora e integre! É simples, fácil, e oferece informações importantes para o seu site. Para completar e evitar que algo semelhante aconteça, confira dicas para aumentar a segurança no WordPress.

Quero aproveitar o espaço para agradecer Leandro Lopes (dono do blog Papo de Buteco), que autorizou a postagem de exemplos relacionados ao blog dele. É importante relatar o que aconteceu, ainda mais com casos verídicos, pois pode acontecer com qualquer um.

Posts Relacionados

• Seu lugar ao sol
• GoMo – Teste seu site mobile
• Agora é a vez dos desenvolvedores
• Boas práticas de Acessibilidade
• Introdução aos padrões de codificação

Você realmente acha que vai escrever CSS e HTML como escreve hoje em um cenário como este?
Você já parou para pensar onde CSS/HTML e Javascript se encaixam em um ambiente onde a web é praticamente camuflada por APPs específicos? Eu não estou me referindo a estes Apps como conhecemos hoje. Podem ser Apps instaladas ou WebApps, neste futuro, dá na mesma. Não há diferença.

Pior do que pensar o lugar que CSS e HTML estarão é pensar em como VOCÊ se colocará em um ambiente tão novo quanto este. O que realmente iremos fazer? Qual será o papel de cada um? Será que a metodologia de trabalho será a mesma?

Você também já deve ter visto o vídeo acima. Veja como os personagens utilizam seus gadgets e como tudo está sincronizado. A discussão aí não é se é melhor criar uma App ou uma aplicação Web, é se o seu produto é realmente relevante e se vai ajudar realmente a vida das pessoas. A forma como isso é oferecido não importa, porque em um cenário como esse tudo é igual. Não faz diferença nenhuma. A Web não é só o seu browser.

É por isso que eu acho que os desenvolvedores precisam acordar. Urgente.
Eu perco as contas de quantos desenvolvedores me castigam quando eu digo para ignorar totalmente os browsers antigos. Você acha que um futuro como mostrado nos vídeos ou qualquer outro tipo de futuro, vai ficar esperando um browser ser adequado aos padrões? Aliás, browsers existirão?

Você precisa repensar o que realmente é vida digital. Qual a real utilidade de se carregar um celular dispositivo móvel. Repense o que será design responsivo. Eu sei que a necessidade de hoje é adaptar websites e aplicações para as diversas telas, mas entende que isso é só uma necessidade que vai passar rápido? Vai passar rápido não porque é uma modinha sem importância, mas porque isso deverá ser padrão daqui pra frente. Assim como o Tableless. Lembra que falavam que isso era uma modinha e que já já passaria? Pois é.

Experimente fazer o exercício de entender o futuro da web. É algo que todo profissional web deveria fazer, principalmente os desenvolvedores. Não importa qual linguagem de programação você vai precisar aprender ou desaprender, o que importa é como ela será aplicada. Isso muda tudo.

Embora a ideia não seja apenas direcionada a Mobile mas para todos os meios de acesso, vale muito a pena ver a apresentação que o Michel Lent fez. Dá uma olhada:

Posts Relacionados

• GoMo – Teste seu site mobile
• Agora é a vez dos desenvolvedores
• Boas práticas de Acessibilidade
• Experiência deve ter começo, meio e fim
• Manipulando a metatag Viewport

O GoMo faz um teste rápido no seu site e mostra um screenshot de como seu site aparece em aparelhos móveis, aparentemente somente em aparelhos que rodam Android. Lembrando que muito provavelmente seu site aparecerá da mesma forma em dispositivos da Apple, que rodam WebKit, mesmo motor de renderização do browser do Android.

Ao final do teste ele entrega o resultando indicando 4 pontos principais: velocidade, imagens quebradas, legibilidade de textos e navegação. Muito interessante para quem quer pelo menos ter um teste superficial de como seu site se comporta nestes dispositivos.

Visite o GoMo.

Posts Relacionados

• Agora é a vez dos desenvolvedores
• ePub: Aprenda a criar um livro digital
• Introdução aos padrões de codificação
• Estruturação de Client-side – Parte 1: Préprocessadores, Framewoks e Bibliotecas
• Qualidade de Imagens e densidade de pixels

Cada um destes personagens tem papéis importantes para que a evolução da web possa se tornar forte, traçando novos caminhos, cobrindo as necessidades atuais dos usuários e prevendo necessidades e soluções futuras. Há um ciclo para que estes personagens possam cumprir com seus objetivos.

O W3C cuida dos padrões. Ele tem ideias, ele prevê problemas e tenta solucioná-los. O W3C não aplica, ele apenas planeja. É um trabalho difícil, por que é necessário uma visão muito apurada do cenário da web para saber quais caminhos ela deverá tomar. Uma decisão errada, pode acarretar problemas que levarão anos para serem solucionados por completo. Vide o desenvolvimento com tabelas. Por isso esse trabalho de planejamento deve ser meticuloso. Devo confessar que em muitos casos o W3C não supera as expectativas e faz com que iniciativas paralelas surjam e direcionem a Web para um caminha mais correto. Foi o que aconteceu com o HTML5.

Os browsers, por sua vez, precisam entender e adotar as idéias do W3C, absorvendo as soluções e criando suporte nos seus softwares. Esse trabalho também tem seus perigos. Os browsers precisam pesquisar quais das necessidades dos desenvolvedores é mais importante e assim implementá-la para que a utilização de projetos seja executada. Obviamente que alguns decidem suportar aquelas soluções que darão mais pontos estratégicos contra o concorrente.

Finalizando o ciclo, os desenvolvedores aplicam tudo o W3C define, mas apenas aquilo que os browsers “querem” ou podem suportar. E isso, claro, faz com que o desenvolvedor se depare com problemas na ponta produção. Vide o IE6/7/8 e nossos problemas de cada dia.

Durante muito tempo, esse ciclo não era afinado. Havia uma certa confusão e um jogo de interesses próprios envolvendo principalmente os browsers. O W3C estava apenas pensando em como resolver problemas que talvez existiriam daqui longos anos. Os browsers estavam apenas interessados em criar uma massa de usuários suficiente para ser o primeiro no ranking. Os desenvolvedores, por sua vez, queriam ganhar seu dinheirinho, fazer o trabalho, entregar pro cliente e acabar com o problema.
Ninguém deu atenção quando começamos a desenvolver com tabelas, fazendo com que os sites ficassem mais pesados, aumentando o tempo de desenvolvimento e o custo do projeto.

Este ciclo defeituoso foi praticado durante muito tempo. Por incrível que pareça, foram os Desenvolvedores que começaram a fazer o ciclo funcionar novamente como deveria. Eles acordaram os fabricantes de browsers e também o W3C.

O W3C passou a pensar mais em problemas presentes. Solucionou problemas iminentes e que entregavam valor para os projetos.

Os browsers suportaram o mais rápido possível essas mudanças, atualizando seus engines, e fortalecendo as bases para novas soluções e flexibilizações posteriores.

Já os desenvolvedores estagnaram. Desculpe-me, serei um pouco revoltado daqui para frente. Os desenvolvedores dormiram. Quando o W3C e os browsers apresentaram soluções para problemas como transparência, bordas arredondadas, backgrounds inteligentes, utilização de fonts remotas e etc, os desenvolvedores resolveram que não era a hora dessas soluções por causa da retrocompatibilidade com browsers antigos, como o IE6. Na verdade estou sendo meio injusto aqui. Não foram todos os desenvolvedores que criaram caso com a retrocompatibilidade, foram somente os idiotas.

Nós reclamávamos que precisávamos de recursos mais inteligentes para trabalhar. Que precisávamos de idéias realmente inovadoras, que transformassem os projetos e facilitassem o desenvolvimento. Protestamos, escrevemos manifestos, postamos em nossos blogs revoltados com a falta de visão do W3C e com a pobreza do suporte dos browsers. E quando conseguimos o que queríamos, demos para trás. Amarelamos. Pedimos arrego.

Infelizmente, via-se muito disso aqui no Brasil do que no resto do mundo. Ouvi muitas desculpas como: – “Mas meu cliente usa IE6.” ou “Mas isso não funciona em IE6.” Você é desenvolvedor. Você trata com seu cliente todos os dias. Você tem o poder de educar e convencer. E se você acha que não tem poder nenhum, por que ainda trabalha com web?

Talvez isso seja trauma do passado. Talvez não. O fato é que não podemos mais nivelar por baixo. Isso é atrasar uma “evolução” inteira.

Tenho incansavelmente falado sobre Graceful Degradation, Enhanced Progressive, HTML 5, as maravilhas do CSS 3 e etc, pois esse é o assunto que rola lá fora. Há desenvolvedores e empresas, que acham que devemos ter uma autorização especial dos gringos para utilizarmos novas tecnologias e principalmente para deixar os browsers antigos no passado.

Esse assunto me faz pensar em outra pergunta: Estamos (você está?) preparados para o ritmo alucinante do W3C e dos browsers?
Até a Microsoft está cumprindo com a palavra de ter um browser atualizado. Eles já anunciaram o novíssimo Internet Explorer 10, com uma série de atualizações que promete trazer o IE para o patamar de browsers atuais.

O mercado de client-side se transformará rapidamente nos próximos anos. Muitas mudanças no HTML e no CSS serão publicadas com o intuito de tornar a web mais homogênea, flexível, portável. O HTML 5 não é só uma coleção de novas tags e APIs. O CSS 3 não ganhou só bordas arredondadas. E nem só de iPhone vive o homem. Existem milhares de Nokias, Blackberrys, Windows Phones e Androids por aí.

Os desenvolvedores precisam acordar.

Artigo originalmente publicado em Nov/2009 na revista TI Digital.

Posts Relacionados

• GoMo – Teste seu site mobile
• Introdução aos padrões de codificação
• Estruturação de Client-side – Parte 1: Préprocessadores, Framewoks e Bibliotecas
• Seu lugar ao sol
• ePub: Aprenda a criar um livro digital

Posts Relacionados

• Qualidade de Imagens e densidade de pixels
• Seu lugar ao sol
• GoMo – Teste seu site mobile
• ePub: Aprenda a criar um livro digital
• Sobre Internet Explorer para Mobile – Breve impressão

Definir padrões é normal para que a equipe inteira escreva o código da mesma maneira. Esse assunto é longo e muito importante para todas as equipes de desenvolvimento. Programadores já quiseram me matar várias vezes porque eu uso TABS em vez de ESPAÇOS em arquivos Python/PHP. Programadores gostam de espaços. Eu não. Mas não é o nosso gosto que vai definir quais os padrões de código que devemos seguir.

Quando definimos padrões e boas práticas, garantimos que todos da equipe conseguirão ter o mínimo de entendimento do código daquele projeto que está na empresa a tempos. Se alguém da equipe adoecer ou precisar ir para o Canadá, outro integrante pode assumir o seu lugar sem precisar se preocupar em aprender novas regras, porque elas devem ser as mesmas do projeto anterior.

É importante que os integrantes da equipe sejam sempre fiéis aos acordos firmados no momento em que combinam esses padrões. É importante também que, caso eles encontrem um integrante fora da lei, que eles forcem o meliante a seguir as regras. Já vi gente perdendo o trabalho de uma semana por que estava trabalhando diretamente pelo FTP e o projeto não estava no GIT. O programador simplesmente APAGOU o projeto da pessoa. Nunca mais ela resolveu editar os arquivos fora do controle de versão. Esse tipo de atitude é perigosa mas muito necessárias às vezes. Devemos forçar as regras num ambiente onde todos devem quem, quando e como as linhas de código do projeto foram escritas.

Alguns pontos para se pensar e combinar:

Identação

Como devemos identar o código? Com espaços ou tabs? Se for com espaços quantos?

Espaços em brancos (Whitespaces)

Espaços devem ser incluídos depois de uma operação condicional? Espaços devem ser colocados entre o seletor e as chaves? E no final de cada linha, precisa?

Nomenclatura

Como as classes, ids e variáveis devem ser nomeadas? E as funções? Vamos usar CamelCase?

Comentários

Como faremos com os comentários? Como serão os delimitadores do comentário? O comentário deve ser completo ou precisa ser algo mais resumido?

Arquivos

Como os arquivos, que não fazem parte da estrutura padrão do CMS, Framework e etc deverão ser chamados? E o nome das pastas? Como as páginas serão chamadas?

Chaves e ponto/vírgula

As chaves deverão ser abertas na mesma linha ou devemos quebrar linhas? Vamos sempre usar ponto/vírgula? Vamos usar o padrão K&R ou Allman?

Quando definimos estas pequenas coisas, diminuímos muitos percalços no meio do caminho. Já vi projetos atrasarem meses por que um palerma abriu e salvou arquivos com o charset diferente do que já tinha sido combinado no início.

“It’s more important for people on a team to agree to a single coding style than it is to find the perfect style.” Building Scalable Web Sites: Building, Scaling, and Optimizing the Next Generation of Web Applications
Indico este livro sobre esse e outros assuntos sobre a construção, desenvolvimento e manutenção de websites

Posts Relacionados

• GoMo – Teste seu site mobile
• Agora é a vez dos desenvolvedores
• Estruturação de Client-side – Parte 1: Préprocessadores, Framewoks e Bibliotecas
• ePub: Aprenda a criar um livro digital
• Introdução das premissas dos controles de versão

O que você tem que fazer é simples:
- Você só pode enviar CSS.
- O seu código CSS deve ter 1K (1024 bytes), minificado.
- Não precisa utilizar prefixos de browsers, eles colocarão lá para você, logo, você pode usar as coisas bacanas de CSS que só funcionam em browsers (não o IE).
- O Design não precisa ficar igualzinho em todos os browsers, mas gracefull degradation é uma boa pedida.
- Seu código é submetido sob a licensa MIT.

Eles dão o código HTML que você não pode modificar em hipótese alguma, se não acaba a graça da brincadeira.

E aí, consegue?

Posts Relacionados

• Agora é a vez dos desenvolvedores
• Um pensamento sobre design para web
• Dicas de sobrevivência em uma era pós o IE6
• Qualidade de Imagens e densidade de pixels
• Seu lugar ao sol

A boa experiência no design de impresso depende muito da arte inspiradora do designer, qual o papel usado, que tipo de impressão, da gráfica… em web dependemos muito do tamanho da tela, do dispositivo utilizado, do browser, da configuração do texto, velocidade da internet e do computador. São muitas variações para tentarmos manter o controle de cada detalhe.

Quando um designer faz peças para uma campanha ou algum projeto offline, dependendo do caso é necessário criar peças para diversos formatos de veiculação em outdoors, revistas, posters etc. Em relação a web, nós temos todos os formatos de telas que envolvem tablets, notebooks, monitores, TVs e celulares… Com um diferencial: cada uma dessas telas tem um tipo de comportamento diferente dependendo da manipulação do dispositivo e também do usuário. Em alguns dispositivos como tablets e mobiles em uma tela temos dois formatos: retrato e paisagem. Já no impresso não há manipulação pelo usuário. A estimulo é totalmente visual e muitas vezes tátil. Mesmo assim, a experiência que a web entrega é totalmente outra.

No design impresso, quanto mais proporcional, harmoniosa e equilibrada for a peça, melhor será recebida. No design para web também, mas os layouts precisam ser harmoniosos em cada um dos dispositivos, precisa ser proporcional em cada navegador, além da acessibilidade para alcançar usuário distantes.

Mas em ambas a personalidade é a plataforma para a emoção do usuário. Seja online ou offline, o layout, a forma com que o usuário o consome deve leva-lo para uma experiência diferente do normal. E não estou falando de hotsites feitos em flashs ordinários puramente comerciais.

Eu queria ser designer para entender melhor os conceitos que envolvem esse assunto e talvez explicar tudo isso com mais propriedade.

Assim como não é possível escrever uma linha de código sem saber os porquês da importância do código semântico e acessível, não é possível desenhar um website sem ter a plena certeza de que qualquer usuário terá uma experiência envolvente e agradável.

O design para web está mudando de novo outra vez por causa da explosão de novos dispositivos. Se você ainda não parou para pensar, pense: faça as contas das telas: notebooks, monitores, tablets e smartphones. Sendo que cada uma destes tipos de telas tem diversas variações de tamanho e principalmente de resoluções. Já disse que a experiência do usuário precisa ser cross-device, caso contrário, algo se perde.

Eu queria mesmo era fazer um carro.

Posts Relacionados

• Experiência cross-device
• Adobe e os Padrões Web
• Qualidade de Imagens e densidade de pixels
• Agora é a vez dos desenvolvedores
• CSS1K

O artigo do Scott Jenson começa dizendo que a popularização dos smartphones são apenas o começo. Juntando o barateamento das peças para a produção destes aparelhos com a criação sistemas de baixo custo e acessíveis como o Android, não só estão surgindo dispositivos baratos capazes de fazer tarefas que antes eram possíveis apenas em computadores, mas dispositivos baratos baseados na web, trazendo uma experiência cross-device nunca antes experimentada. Um exemplo disso é quando utilizamos estes dispositivos integrados com aplicações como o sistema de som Sonos. O Scott Jenson chamada de Zombie Apocalypse dos eletrônicos.

O paradigma dos computadores desktops estão nos impedindo de enxergar novos caminhos não tão longes assim. Isso é totalmente evidente quando falamos sobre smartphones, no qual nós sabemos que não são computadores desktops e tão somente por isso nós temos outras experiências e outras abordargens quando estamos usando aparelhos deste tipo. Perceba que diversos serviços e aplicações estão sendo portados para os dispositivos móveis porque fazem mais sentido nesse meio. O Twitter mesmo foi criado inicialmente para publicações vindas apenas pelos smartphones. Foi um processo reverso.

Me lembro que aqui no Brasil o recebimento de SMS internacional era um problema em algumas operadoras. Muitos queriam utilizar o Twitter, mas não podiam atualizar suas timelines ou receber as atualizações dos seus colegas porque o Twitter, naquela época, era baseado em SMS. Foi aí que a plataforma se popularizou mais lá fora e então a possibilidade de atualizar sua timeline por outros meios surgiu.

Há uma frase interessantíssima no artigo de Scott Jenson onde ele diz assim:

This problem is simple, but pernicious: designers think of new technologies in terms of yesterday’s tasks, failing to clearly see the real potential of the new technologies.

Minha tradução livre: “O problema é simples mas pernicioso: os designers pensam nas novas tecnologias baseando-se nas tarefas de ontem, falhando em ver claramente o real potencial das novas tecnologias.”

Muito óbvio. É por isso que o Windows Mobile falhou! A Microsoft durante muito tempo liderou o mercado de sistemas para mobiles com um sistema ruim, bugado e muito, mas muito inútil, simplesmente porque eles eram praticamente os únicos. O problema com o sistema deles foi a tentiva de portar os conceitos, experiências, comportamentos e tarefas do sistema dos desktops para os mobiles. Claramente um grande erro. Com o Windows Phone eles mudaram (tarde) o cenário. Eles criaram o Windows Phone levando em consideração os atos e comportamentos do usuário em aparelhos deste tipo. Não há nenhuma analogia aos desktops. E mais uma vez, algo que foi criado primeiramente para aparelhos móveis será portado para os desktops, que é o caso da interface Metro levada para o Windows 8.

Os PCs de hoje serão apenas hubs num futuro próximo. No cenário de hoje você escolhe entre Mac ou PC e baixa aplicativos que muito provavelmente funcionarão apenas para um destes sistemas. O modelo ideal, que já é mais real do que imaginamos, é que cada pessoa possa usar múltiplos dispositivos acessando um mesmo dado, uma mesma informação, normalmente pela núvem.

O exemplo do serviço de música via streaming Pandora é perfeito. Ele permite que nós possamos utilizar seus serviços em uma variedade gigante de dispositivos. Sempre sincronizando suas músicas via internet. Tudo sempre integrado. Aqui no Brasil, como o Pandora não funciona, talvez não seja a sua realidade… Entretanto estamos vivendo em um mundo onde o software, a aplicação, o serviço, define qual aparelho você vai comprar.

O Sonos é um aparelho de som Wi-Fi. Além do Pandora você pode sincronizar sua biblioteca de músicas de diversos outros serviços como iTunes ou o Spotify. Quando o conheci eu o quis sem pensar. Nada de iPod ou iPhone plugado no aparelho de som. Nada de fio p2-p2 para ligar meu celular ao aparelho de som… Eu quero ouvir minhas músicas livremente pelo serviço que eu mais gosto no sistema de som da minha casa. Mas quando eu for pra rua e quero continuar ouvindo a mesma biblioteca de música, só que agora no meu fone de ouvido. Essa integração entre dispositivos e softwares é incrível. Perceba que não estamos falando sobre um ecosistema fechado como o da Apple. Estamos falando de hardware e software de fabricantes diferentes, que prestam diferentes serviços, mas que se integram.

Entende o que é a experiência do usuário nesse cenário?

Posts Relacionados

• Um pensamento sobre design para web
• Vote no Especialista em Usabilidade para Presidente
• Sites para Dispositivos Móveis – MediaType
• Sobre Internet Explorer para Mobile – Breve impressão
• Adobe e os Padrões Web

Afinal, o que é usabilidade?

A Usabilidade é “filha” da Interação Humano-Computador (IHC) e “neta” da Engenharia de Software, carregando esse legado ao longo de sua evolução, podendo ser definida como o grau de facilidade com que o usuário consegue interagir com determinada interface.

Partindo da IHC, a usabilidade aborda a forma como o usuário se comunica com a máquina e como a tecnologia responde à interação do usuário, considerando as seguintes habilidades, de acordo com a norma ISO 9241:

• Facilidade de aprendizado: a utilização do sistema requer pouco treinamento;
• Fácil de memorizar: o usuário deve lembrar como utilizar a interface depois de algum tempo;
• Maximizar a produtividade: a interface deve permitir que o usuário realize a tarefa de forma rápida e eficiente;
• Minimizar a taxa de erros: caso aconteçam erros, a interface deve avisar o usuário e permitir a correção de modo fácil;
• Maximizar a satisfação do usuário: a interface deve dar-lhe confiança e segurança.

Partindo da Engenharia de Software, a usabilidade é englobada dentro da qualidade e visa garantir uma parte da eficiência e eficácia do sistema. A eficiência refere-se a uma interação produtiva entre o usuário e o sistema, permitindo a realização de tarefas com menor esforço sob uma experiência agradável. A eficácia pode ser entendida como a capacidade do sistema e da interface possibilitarem ao usuário a completude da tarefa e o alcance de seus objetivos no sistema.

A importância da usabilidade no desenvolvimento de projetos

A usabilidade se encaixa em qualquer tipo de projeto de interface, tendo amplitude diferente de acordo com a criticidade do projeto, ou seja, quanto mais crítico for o sistema, maiores serão as perdas caso ele não seja de fácil utilização e proporcione satisfação. Ela deve ser pensada desde o planejamento do projeto, até a etapa de desenvolvimento e teste.

As empresas têm consciência da importância da usabilidade. Porém, muitas ainda a veem como um fator que só deve ser levado em conta durante o desenvolvimento se houver tempo e recurso, como se ela representasse um custo adicional, fora do que é essencial. Mas as empresas têm muito mais a perder ao minimizar a usabilidade dessa forma. De acordo com Cybis, Betiol e Faust (2007):

“Dependendo da frequência com que o software é empregado, os prejuízos para as empresas podem também ser expressivos, não só em decorrência do absenteísmo e da rotatividade do pessoal, mas também pela baixa produtividade, competitividade e menor retorno de investimento. Sistemas difíceis de usar implicam em erros e perda de tempo, fatores que se multiplicam com a frequência das tarefas e o número de usuários. A perda de dados e informações pode implicar na perda de clientes e de oportunidades. Acontecimentos deste tipo causam desde uma resistência ao uso do sistema até a sua subutilização e abandono completo, com o devido consentimento da empresa. O barato terá custado caro.”

A usabilidade pode ser abordada de diferentes formas ao longo do projeto:

Técnicas utilizadas para garantir e verificar a usabilidade em diferentes etapas

Lacunas a serem preenchidas

Apesar de a usabilidade ser responsável por assegurar grande parte dos quesitos de experiência do usuário, ela possui duas grandes limitações:

1. Embora considere a satisfação do usuário, trata apenas dessa satisfação perante a realização de uma determinada tarefa, concentrando-se na função, sem considerar fatores físicos, ambientais e emocionais inerentes ao contexto de utilização do sistema. Mais do que ser de fácil utilização, aprendizagem e permitir completude da tarefa, uma boa experiência de uso está baseada em uma interação agradável, considerando a forma como as pessoas percebem a interação com o sistema;
2. O contexto usualmente analisado pela usabilidade é mais restrito: abrange apenas a visão do usuário. Para garantir uma boa experiência de uso, é necessário abranger a visão de diferentes stakeholders: do usuário, da organização e da equipe de desenvolvimento, cada qual com requisitos e necessidades diferentes frente ao sistema.

Adaptando um gráfico apresentado durante a nnGroup Conference de 2008, podemos ver a usabilidade enquadrada da seguinte forma:

O escopo da usabilidade

Referências e Leitura Complementar

ABRAS, C.; MALONEY-KRICHMAR, D.; PREECE, J. User-Centered Design. In: Bainbridge, W. Encyclopedia of Human-Computer Interaction. Thousand Oaks: Sage Publications, 2004.

CYBIS, W.; BETIOL, A. H.; FAUST, R. Ergonomia e Usabilidade: Conhecimentos, Métodos e Aplicações. São Paulo: Novatec Editora, 2007. 344p.

SUMATHI, B. Chapter Three: User Centered Design Approach. Disponível em: http://dspace.fsktm.um.edu.my/bitstream/1812/214/8/Chapter%20Three.pdf.

NIELSEN, J.; LORANGER, H. Usabilidade na Web: Projetando Websites com qualidade. Rio de Janeiro: Elsevier, 2007. 406p.

OLIVEIRA NETTO, A. A. IHC – Interação Humano Computador: Modelagem e Gerência de Interfaces com o Usuário. Florianópolis: VisualBooks, 2004. 120p.

PREECE, J.; ROGERS; Y.; SHARP, H. Interaction Design: Beyond Human-Computer Interaction. New York: John Wiley & Sons, Inc., 2002. 551p.

ROCHA, H. R.; BARANAUSKAS, M. C. C. Design e Avaliação de Interfaces Humano-Computador. Campinas: Universidade Estadual de Campinas, 2007.

UX Revisions. The Difference Between Usability and User Experience. Disponível em: http://www.uxrevisions.com/user-experience-design/the-difference-between-usability-and-user-experience/18/

UX Revisions. User Experience vs User Interaction. Disponível em: http://www.uxrevisions.com/user-experience-design/user-experience-vs-user-interaction/16/

Usability Geek. The Difference (And Relationship) Between Usability And User Experience. Disponível em: http://usabilitygeek.com/the-difference-between-usability-and-user-experience/

NeoSpot. Usability vs. User Experience (UX). Disponível em: http://neospot.se/usability-vs-user-experience/

Interaction by Design. Usability vs. user experience. Disponível em: http://www.interactionbydesign.com/thoughts/thumbnails/00000050.html

Posts Relacionados

• Experiência deve ter começo, meio e fim
• Responsabilidade de um dev client-side
• Entendendo quais APIs (realmente) fazem parte do HTML5
• Seu lugar ao sol
• GoMo – Teste seu site mobile