Arquitetando Informações
fevereiro 3rd, 2010
Arquitetura de Informação, Design centrado no usuário e Usabilidade sempre me interessaram, mesmo antes de sequer eu conhecer esses conceitos de uma forma mais aprofundada ou trabalhar diretamente com eles.
Acho super gratificante para um arquiteto de informação ver o seu rascunho e suas pesquisas se transformarem em produtos ou serviços para os usuários da web. Partir dos mapas mentais, modelos de publicação e matrizes de componentes e conteúdo para finalmente aplicar testes com o usuário e captar as suas reais necessidades e desejos.
Costumo falar que o arquiteto de informação projeta e materializa as idéias do cliente para trazer a tão esperada satisfação subjetiva daquele que vai utilizar o site ou sistema interativo. Daí vem o “arquitetar informações”, assim como o arquiteto tradicional aplicamos os conceitos de design e ergonomia só que para um outro ambiente, o digital
Links interessantes
fevereiro 1st, 2010
Links interessantes sobre usabilidade:
- Por que o 640 x 480 ainda não está morto. Algo mais que resolução de tela.
- Um site muito interessante. Artigos sobre usabilidade com exemplos aplicados e os resultados que obtiveram.
- No mesmo site se oferecem endereços para ver estatísticas sobre web browser, resolução de tela, etc..
- site usability, uma jóia
- Usabilidade em Microsoft. (Inglês, gratuito)
- Mais usabilidade em Microsoft. (Inglês, gratuito)
- 10 pontos de usabilidade (Inglês, gratuito)
- Artigos variados… (Inglês, gratuito)
- Dando serviço aos clientes (Inglês, gratuito)
- Dack.com. Usabilidade, stocks, golf e música… em alguns momentos é muito divertido. (Inglês, gratuito)
- Flazoom.com. Para desenvolvedores de flash. (Inglês, gratuito, recomenda-se ter o plugin de flash)
- Joel. Usabilidade para programadores. (Inglês, gratuito)
- Mediametrix. Saiba que páginas são as mais visitadas. (Inglês, gratuito)
- Gomez. Analisis de web sites y rankins. (Ingles, gratuito)
- Boston Consulting group. Consultora especializada en temas on-line. (Ingles, gratuito)
- Upsdell.com. Estatísticas. (Inglês, gratuito)
- Nua. Estatísticas e dados. (Inglês, gratuito)
- OJD. Estatísticas. (Espanhol, gratuito)
- Useit Usabilidade. (Inglês, gratuito)
Os usuários não são adivinhas
novembro 22nd, 2009
Neste artigo indicaremos quais elementos ajudam o usuário a navegar e quais não. Ademais, tentaremos indicar que elementos ajudam a predizer ao usuário seu destino ao clicar um link.
Aqui estão ordenados de mais a menos aqueles elementos que claramente indicam ações de clicar e mudar de página.
- Os links em azul e os botões do sistema (não se incluem combos).
- Os links em outra cor que não seja azul, perdem parte da chamada de link.
- Os botões que não são do sistema. A aba, talvez seja um bom exemplo mais extenso, mas há outras opções.
- Links sem sublinhar que mudam de cor ou ficam sublinhados ao passar por cima.
- Fotos. O tamanho da foto ajuda que se passe por cima e se evidencie a opção de clicar. Outra opção que ajuda o usuário a clicar nas imagens, é o fato de que esteja com uma borda. Esta borda terá a mesma cor que os links, portanto ajudará ao usuário a reconhecer o link.
- Combos. O combo é uma ferramenta de seleção, e não de ação. Mesmo assim, não se recomenda nem para fazer seleções. O combo não é uma ferramenta recomendável, porque em geral, deixa o usuário inseguro sem saber muito bem o que acontece quando clica sobre ele. Seu uso é recomendado em formulários ou operações, mas nunca em navegação.
- Texto ou imagens sem sublinhar que não mudam de cor.
Com esta ordem recomendamos que sempre use links azuis e botões do sistema.
Como diz o título desta página, o usuário não é bobo, mas também não é adivinha e será mais fácil para a navegação se indicarmos claramente quais elementos têm links e quais não. Lembre-se que quanto mais fácil pareça, mais páginas visitará, mais banners verá, mais produtos olhará….
Um dado importante na hora de fazer botões é o tamanho dos mesmos, a relação de tamanho em relação à tela deve ser proporcional já que ajudaremos ao usuário a acertar na hora de clicar.
Outro dado importante é o de evitar os espaços em branco na navegação. Procure fazer com que os botões fiquem claramente contornados e que este contorno não se rompa. Se colocar uma imagem e embaixo um texto que explica o que é, procure fazer com que o espaço entre o botão e o texto também seja clicável.
Exemplo de bons botões:
Estes botões ordenados da esquerda à direita, são um bom exemplo de como fazer botões que funcionem.
- Ver biografia. (Correto)
- Para ver a biografia clique aqui. (Incorreto)
Usar a tag de title nos links ajuda a saber o que é que vamos ver. Alguns navegadores não o lêem, mas sempre ajuda e não é incompatível.
- Ver biografia. (Recomendável)
Se o link nos dirige a outro servidor, é bom pintar o endereço.
- Ver biografia (http://dominio.com/biografia/) . (Recomendável)
O que se recomenda nestes casos, é deixar o link aberto a todo os botões e não obrigar o usuário a utilizar ou preencher o passo 1 para ver o passo 2. Em muitos formulários se utiliza este sistema de 1, 2 e 3, mas não deixa ver o conteúdo do 2 ou do 3 até que se preencha o 1. É melhor deixarmos todos abertos para que o usuário explore e não encadearmos os passos obrigando o usuário a utilizar todo o sistema.
2. Ofereça ao usuário a informação necessária sobre onde está e aonde pode ir de forma clara.
3. Ofereça guias ao usuário (1, 2 e 3, primeiro isso, logo aquilo, lhe recomendamos isto).
4. Os elementos que carregam a página devem ser indicados claramente.
O que matou o RUP pode matar o Agile
novembro 22nd, 2009
Na virada do Milênio, eu ví pessoas e empresas buscando processos como o RUP e outros pela motivacão errada. Eles achavam que a maneira “falar com o usuário – implementar – entregar” era pouco controlada. O pensamento era: “Ninguém assina nada?”. Nessa época os gerentes voluntariamente queriam uma burocratização. Era proibido falar as palavras empírico e pragmático nesta época. Não importando o Manifesto Ágil publicado em 2001, aqui no Brasil o que eu ví foi adoção de processos por pura burocratização.
O que matou o RUP foi a falta de entendimento, e isso é o que vai matar o Agile. Lean é o próximo da fila. Escreva aí: em 5 anos, dependendo dos ventos da economia e do clima empresarial, muitos vão estar criticando Agile do mesmo modo que hoje criticam o RUP, sem autoridade de causa. Tudo vai depender do mindset vigente no momento. Tudo depende do mindset: se você der o Scrum e XP para um “tradicionalista” ele não vai mudar seu mindset, mas sim adaptar o Scrum e o XP às suas “crenças”. Se você der o RUP para um pragmático, ele também não muda o seu mindset, mas sim, adapta o RUP à sua realidade. Você pode decidir o seu mindset: ou você realmente acredita nos 4 valores e 12 princípios ágeis e adota este estilo, ou você se enche de penduricalhos ágeis só para ficar na modinha
Veja artigo completo no blog da Aspercom
Só agilidade funciona
novembro 22nd, 2009
“Se o RUP verdadeiro fosse o adotado nas empresas todas seriam ágeis e este artigo não precisaria existir.”
Artigo retirado do blog da Aspercom
Modelo Tradicional x Modelo Ágil
A pergunta que me levou a escrever é: O que é o Modelo Tradicional? Durante aproximadamente uns 2 meses perguntei em praticamente todos os fóruns de discussão que participo (veja links do Blog) o que seria o modelo tradicional. Essa pergunta foi provocativa, mas ao mesmo tempo elucidadora para muitos. O fato é que NINGUÉM soube responder o que é o Modelo Tradicional. Ninguém soube explicar, ou citar, que autor escreveu ou defendeu algo chamado “Método Tradicional de Desenvolvimento de Software”. Nenhum modelo de processo é Tradicional. O Modelo Tradicional não existe.
Alguns citaram que o modelo tradicional é o Waterfall. Bem, como expliquei aqui, o Waterfall não é defendido em nenhuma literatura. Ok… ele pode ser tomado como tradicional pois é o modelo mais utilizado, porém, o modelo waterfall não tem sustentação teórica. Nenhum autor sério defende waterfall. Como pode pois a nossa indústria estar usando um modelo que desde o nascimento foi taxado como anti-pattern? Se o Waterfall é o modelo tradicional, seguimos uma tradição bem burra.
Outros citaram que o modelo tradicional é o RUP. Mais uma discordância aqui. O RUP é um “agile process framework”. Jacobson, Larman, Booch, Ambler são Rupeiros de plantão como eu e praticam agilidade. O problema com o RUP é que poucos compreendem o RUP. Já ví muitos “especialistas” em RUP falando muita besteira no mercado. Aqui no Brasil conheço 5 a 10 pessoas que realmente conhecem o RUP. O mercado tem um poder enorme de deturpar coisas que ele não compreende (quantas vezes você não ouviu sarcasticamente que XP “é aquela metodologia que são dois programadores por micro”?). O RUP verdadeiro, o que consta na literatura, é ágil. Se o RUP verdadeiro fosse o adotado nas empresas todas seriam ágeis e este artigo não precisaria existir.
Outros citaram o SWEBOK como sendo o Modelo Tradicional. Bem, o SWEBOK é um body-of-knowlegde jogado as moscas. Ninguém tá procurando hoje SWEBOK. SWEBOK surgiu recentemente, assim, não poderia ser tomado como Tradicional. O RUP é um body-of-knowledge mais maduro e mais experimentado que o SWEBOK.
Se você nunca parou para pensar pergunte a sí próprio: Quem falou que desenvolvimento de software é sequencial como Caso de Uso – UML – Codificação e Teste? Quem disse que Gantt Chart é bom para desenvolvimento de software? Que pesquisa revelou que especialização e divisão do trabalho é uma boa idéia para software? Por que eu tenho que levantar todos os requisitos antes? E a principal: Se waterfall funciona por que meus clientes estão insatisfeitos?
Essas práticas não tem o mínimo fundamento teórico, nenhuma literatura prega que desenvolvimento de software é assim. Sim, você que é universitário pode questionar seu “mestre”, pois muitos não tem a mínima noção ou experiência no que estão ensinando. Essas práticas erradas são “idéias” que gerentes burros adotaram simplesmente fazendo um comparativo com linhas de produção da indústria. Eles se encheram de práticas sequenciais e colocaram uma placa na frente da empresa: “Fábrica de Software”. Eles simplesmente viraram as costas para os avanços da tecnologia e desenvolvem software como se estivessem furando cartões em 1960.
Com isso colocado, não vejo o mínimo sentido as pessoas afirmarem que são “tradicionalistas” no desenvolvimento de software e por isso não são ágeis. Não faz sentido pessoas dizerem “Eu desenvolvo software no modelo tradicional e estou estudando modelos ágeis”. Se você parar para pensar, essa pessoa começou agora a estudar desenvolvimento de software. Não confunda tradicionalismo com burrice.
Agilidade não é falta de controle
Como o já citado “devaneio inconsequente“, o mito mais comum é que modelos ágeis são descontrolados e que não dão informações para o gerenciamento. Quando falamos sobre controle temos que ter em mente o que realmente queremos com o projeto.
# Como podemos planejar e ter precisão nas nossas estimativas?
# Como devemos capturar os reais desejos do cliente?
# Como incorporar as constantes mudanças no projeto?
# Como fazer com que as mudanças não impactem aquilo que funciona?
# Qual arquitetura é a certa para meu projeto?
# Como garantir a manutenção futura do sistema?
# Como saber o real andamento do projeto de uma maneira livre de riscos?
# Como ter certeza que estamos satisfazendo a real necessidade do cliente?
# Como fazer a equipe não se dispersar?
# Como manter a documentação atualizada?
# Como manter prazo e planejamento num projeto em constante mutação?
# Como me antecipar aos riscos?
# Quais são as ferramentas certas?
# Como evitar correrias, horas extras e a explosão de custo no final do projeto?
# E a melhor de todas: Como fazer o projeto ser entregue muito antes do prazo?
Creio que estas e muitas outras perguntas são dúvidas muito frequentes para qualquer equipe que desenvolve software. O mais interessante é que a resposta está na frente deles e se chama AGILIDADE.
Os modelos ágeis são os modelos MAIS CONTROLADOS QUE EXISTEM. Se eu disser para você é possível fazer com que a equipe trabalhe motivada, focada em objetivos e que a assertividade das estimativas são muito próximas de 100% você acreditaria? Se eu disser para você que o simples fato de planejar baseado em objetivos e promover uma reunião diária de 15 minutos pode fazer com que a comunicação enriqueça e que o cliente sempre fique satisfeito mesmo com algumas falhas você acreditaria? As práticas do Scrum (que são baseadas no RUP) promovem esse tipo de controle.
Outros pontos. Se eu falar para você que com seu código coberto de testes automatizados você poderá incorporar mudanças com uma segurança total você acreditaria? Se eu falar pra você que esses mesmos testes automatizados podem servir como documentação dos requisitos e do design de maneira executável, e que através de um relatório de cobertura e muitas outras ferramentas deterministas é possível saber se a “documentação” está atualizada de fato, você acreditaria? Essas são práticas do XP e da TDD.
Se eu falar para você que aproximar o cliente da equipe de desenvolvedores, promover a colaboração e colocar “dois programadores para trabalhar numa mesma máquina” trocando pares é um excelente mecanismo para ganhar produtividade removendo atividades inúteis você acreditaria?
A melhor resposta para o controle são práticas ágeis. Até o momento nenhum outro modelo provou ser eficaz. Nem Gantt, nem PMBOK, nem CMMI, nem MPS.BR são modelos completos que garantem respostas para as perguntas acima. Muito menos um mito, um dogma, um devaneio inconsequente que se criou nas mãos de pessoas que não sabem desenvolver software e chamaram isso de “tradicionalismo”.
Práticas ágeis não competem com “alguma outra coisa” que funciona.
Conclusão: (pela milésima vez)
O modelo tradicional não existe.
Só Agilidade funciona.
Um novo olhar!
novembro 22nd, 2009
Para quem não sabe sou um admirado e apreciador das metodologias ágeis de desenvolvimento de software e diante de minhas pesquisas e busca por conhecimento e aprofundamento neste assunto encontrei este blog da aspercom, uma empresa que atual na difusão da metodologias e tecnicas de desenvolvimento ágeis. O blog possui muito conteúdo e de boa qualidade para quem está começando ou deseja se aprofundar. Separei dois artigos que, entendo ser fundamental para quem está entrando neste mundo de agilidade:
1- O que matou o RUP pode matar o Agile
2 – Só Agilidade funciona
Tive a oportunidade de conhecer e participar de um treinamento sobre Scrum do Rodrigo Yoshima(autor dos posts) , profissional de grande capacidade técnica e bastante experiência com metodologias ágeis.
Conceitos para avaliar usabilidade – part 3 – (final)
outubro 1st, 2009
Satisfação do usuário é importante. Mas como medi-la? Testando a linguagem corporal manifestada durante o uso de uma interface e aplicando questionários detalhados, por exemplo.
Lembram quando eram comuns os anúncios com a frase é satisfação garantida ou seu dinheiro de voltará? Sempre achei engraçado e desde criança ficava intrigado. E seu eu comprar, não gostar e o pessoal não quiser devolver o dinheiro?
Bons tempos aqueles… o cliente se dava por satisfeito, e quase grato, pelo simples fato de comprar um produto e ele funcionar, ou ir a um médico e ser atendido, como se os produtos não fossem feitos para funcionar ou os profissionais basicamente não tivessem que cumprir seus papéis.
Hoje o cliente conhece seus direitos e sabe que pode e deve exigir máxima qualidade dos produtos ou serviços que adquire. A antológica expressão “satisfação garantida…” tem rareado dos anúncios.
Satisfação do cliente… no nosso caso, como medir a “felicidade” ou a satisfação de um cliente ou usuário de websites?
Ao contrário dos demais parâmetros de usabilidade apresentados anteriormente, a satisfação do usuário é mais difícil de ser verificada, pois envolve fatores subjetivos e idiossincráticos do usuário. Satisfação se refere ao nível de conforto que o usuário sente ao utilizar a interface e também ao nível de aceitação desta interface como meio de alcançar seus objetivos.
Para Philippe Kotler, satisfação é o sentimento de prazer ou de desapontamento resultante da comparação do desempenho esperado pelo produto (ou resultado) em relação às expectativas da pessoa. Em um contexto altamente competitivo, devido à oferta ampliada de informações e serviços cada vez mais similares, obter dados sobre o nível de satisfação do usuário é tarefa urgente. Esses dados podem ser obtidos de maneira qualitativa e quantitativa.
Uma maneira qualitativa de se obter dados sobre o nível de satisfação do usuário é observar a linguagem corporal manifestada durante o uso de uma interface. Observar as “caras e bocas”, as mudanças de postura e registrar as verbalizações espontâneas auxilia na percepção do nível de satisfação. Também é importante realizar entrevistas contextuais, que busquem levantar junto ao usuário sua opinião a respeito da interface. Para realizar uma análise qualitativa das atitudes do usuário, o observador dever ter sensibilidade e experiência para perceber o quanto as variações de atitude se relacionam a problemas encontrados durante a interação com o site.
Durante uma entrevista, o observador pode perguntar como o usuário se sente ao usar o site, se foi fácil de usar ou se foi frustrante e complicado. O pesquisador Jakob Nielsen afirma que é melhor realizar a entrevista de forma contextualizada, enquanto o usuário interage com a interface do site, ao invés de somente após o final do uso.
A análise quantitativa da satisfação do usuário pode ser realizada com aplicação de questionários que utilizem escalas de avaliação.
O pesquisador da Universidade de Maryland Ben Shneiderman e sua equipe desenvolveram uma ferramenta denominada Questionaire for User Interface Satisfaction – QUIS. Este questionário divide a usabilidade geral do sistema em componentes e sub–componentes, de forma que o usuário possa registrar, em escalas numéricas, qual sua opinião sobre os diversos elementos com os quais interage, como cores, tipos de letras, imagens e sons e mesmo a linguagem utilizada.
Estes questionários são então tabulados e os resultados quantitativos apresentam para o observador um painel do nível de satisfação dos usuários. Esse tipo de questionário, para que tenha validade, deve ser aplicado com um número razoável de pessoas. Jakob Nielsen sugere que questionários para verificar a satisfação do usuário sejam aplicados com, no mínimo, 20 pessoas.
Tanto a abordagem qualitativa quanto a abordagem quantitativa podem ser utilizadas conjuntamente, para se obter informações a respeito do nível de satisfação do usuário.
Aumentar a usabilidade de um web site implica entender os fatores subjetivos e buscar maneiras de proporcionar ao usuário experiências que, além de pautadas em efetividade e eficiência, também sejam agradáveis e satisfatórias subjetivamente
Por Robson Santos – [Webinsider] clique veja matéria original
Conceitos para avaliar usabilidade – part 2
outubro 1st, 2009
Ao buscar informações em um site de determinada universidade bastante conceituada do Rio de Janeiro, entrei, por curiosidade, em uma área destinada a oportunidades de estágios.Alguns anúncios ofereciam vagas para alunos de Desenho Industrial trabalharem em equipes de desenvolvimento de sites. Até aí, tudo bem. Acontece que alguns anúncios pediam, além dos conhecimentos das ferramentas usuais de webdesign, também conhecimentos de usabilidade.
Há duas questões relacionadas aí. A primeira delas é a confirmação de que existe uma demanda real no mercado por sites com melhor usabilidade e por pessoas capacitadas a exercer atividade projetual que leve em consideração as recomendações de boa usabilidade.
A outra é perceber, também, que há uma necessidade de preparo de docentes capacitados a transmitir para os alunos conhecimento dessa ordem. Quem migrou da mídia impressa para a digital percebe a maior complexidade inerente a projetos desse tipo. Não bastam conhecimentos de design, mas também conhecimentos de tecnologia e de ferramentas. É necessário também conhecer as regras e limitações características da mídia para, criativamente, desenvolver soluções diferenciadas de projeto.
Essas questões tornam cada vez mais pertinente o esforço de se apresentar maneiras para melhorar a usabilidade de um website e aprimorar seu desempenho. Em artigo anterior (veja ao lado), apresentamos alguns conceitos introdutórios relacionados à usabilidade de websites e parâmetros para se medir seu desempenho. As medidas citadas foram efetividade, eficiência e satisfação.
O conceito de efetividade pode ser definido como a capacidade do sistema permitir que o usuário atinja seu objetivo primário de interação. Todo website possui uma tarefa primária a ser executada pelo usuário: busca de informação, compras, comunicação e outros.
Os sites, de maneira geral, são orientados a processos, ao invés de orientados a produtos, como uma planilha eletrônica ou processador de texto, onde o usuário gera um documento que pode ser gravado em seu computador. Como exemplo peculiar de site orientado a processo podemos citar os sites de busca.
Nos sites de busca o usuário inicia o processo com a inserção das palavras–chave e aciona o mecanismo que, após processamento, apresenta as informações recuperadas relacionadas às palavras–chave. Uma característica marcante de sistemas orientados a processos é que a interação do usuário não altera o estado original do sistema e nem cria nenhum documento de posse do usuário.
Nos sites de comércio eletrônico o processo se inicia com a busca por um produto, segue pela seleção e é finalizado com a confirmação da compra. Nada resta, materialmente falando, para o usuário a não ser aguardar que os produtos adquiridos sejam entregues. O processo gera alteração na base de dados do sistema, à qual o usuário não tem acesso.
Nesses dois exemplos, após a finalização da tarefa, não é possível alterar os resultados obtidos, a não ser a partir do reinício do processo, diferentemente do que acontece com um processador de texto onde se pode, a qualquer momento, abrir o documento original, fazer alterações e gravar novamente.
Para avaliar o resultado de uma ação executada em interface de sistema orientado a processo, o usuário faz uso de seus recursos cognitivos para saber se atingiu o objetivo proposto inicialmente.
No caso de um mecanismo de busca, deve ser possível verificar se as informações recuperadas são satisfatórias, ou se será necessário reiniciar o processo até que atinja seu objetivo inicial. Monitorar a qualidade da saída de informações finais do processo de interação é uma forma de assegurar a boa efetividade de um website.
Para aprimorar a efetividade de um site é necessário conhecer em detalhes qual a tarefa a ser realizada e, principalmente, saber como o usuário a realiza em situação real e também em situações do mundo físico.
Desta forma, já se saberá, desde o início do processo de projeto, quais os requisitos necessários para se alcançar a completude da tarefa. Existem técnicas, como a análise da tarefa, que permitem conhecer o modo operacional do usuário e traduzir os dados obtidos em referências para o projeto.
Por exemplo, antes de se projetar um site para uma biblioteca, é importante saber como as pessoas se comportam em uma biblioteca “de verdade”, no mundo físico. É a partir do entendimento de como o usuário pensa e executa a tarefa que se pode projetar sistemas e interfaces web mais adequados às reais necessidades de uso.
Por Robson Santos – [Webinsider] clique veja matéria original
Conceitos para avaliar usabilidade – part 1
setembro 28th, 2009
Percebo com imensa satisfação o interesse crescente a respeito de assuntos relacionados com a usabilidade e com a satisfação do usuário por parte dos profissionais web e outras mídias interativas.
Com o aumento exponencial da concorrência entre sites de boa qualidade, se torna mais fácil perceber que conteúdo não é mais um diferencial, e sim uma commodity. Desta forma, é necessário possuir recursos e conhecimento suficientes que permitam atingir o público certo e mantê–lo fiel e satisfeito com o produto. A preocupação com a boa usabilidade do site é um ponto de partida para alcançar e manter um posição favorecida no mercado.
Nas duas últimas décadas, diversos autores têm se debruçado sobre o tema “usabilidade”, desde que os computadores passaram a ser utilizados por um maior número de pessoas seja para trabalho, estudo ou atividades domésticas. Muitas definições sobre o que é usabilidade têm sido emitidas, mas existem algumas com as quais me identifico.
Por exemplo, o pesquisador francês Dominique Scapin considera que a usabilidade está diretamente ligada ao diálogo na interface e é a capacidade do software em permitir que o usuário alcance suas metas de interação com o sistema. Para Jakob Nielsen, ser de fácil aprendizagem, permitir utilização eficiente e apresentar poucos erros são os três aspectos fundamentais para a percepção da boa usabilidade por parte do usuário.
Ainda existem alguns outros fatores que servem com delimitadores para o conceito e ajudam a definir o escopo do termo usabilidade. Antes de qualquer coisa, o site deve ser de fácil aprendizagem, pois todos sabemos que o tempo de aprendizagem de um website é zero. Não dá para enviar um manual de uso para cada possível usuário ensinando onde se localiza a barra de menus, ou como finalizar a compra. Desta forma, é a através da própria interface que usuário deve perceber a forma de uso do sistema, que, por sua vez deve permitir que os usuários alcancem níveis de desempenho aceitáveis dentro de um determinado período de tempo.
Também é comum pensar em medidas para usabilidade, pois servem como parâmetros para avaliar o nível de usabilidade de um sistema ou de uma interface. As medidas de usabilidade mais freqüentemente consideradas são: efetividade, eficiência e satisfação.
Um site com boa efetividade permite que o usuário alcance os objetivos iniciais de interação. Se for um site de comércio eletrônico, que o usuário realize a compra ou mesmo uma consulta de preço. Se for um site de notícias, que o usuário consiga ler as manchetes e aprofundar algum assunto de interesse, ou pesquisar matérias anteriores. A efetividade geralmente é observada em termos de finalização de uma tarefa e também em termos de qualidade do resultado obtido.
Somando–se à efetividade, a outra medida de usabilidade, a eficiência, se refere à quantidade de esforço necessário para se chegar a um determinado objetivo. É claro que, quanto menos trabalho, melhor… Então não é suficiente permitir que o usuário atinja o objetivo e realize a tarefa, mas que o faça com o menor esforço possível. Os desvios que o usuário faz durante a interação e a quantidade de erros cometidos podem servir para avaliar o nível de eficiência do site. Por isso, oferecer rotas alternativas e atalhos para o conteúdo ou para a finalização da tarefa pode ser uma boa maneira de tornar o site mais eficiente.
A terceira medida de usabilidade, satisfação, talvez seja a mais difícil de medir e quantificar, pois pode estar relacionada a fatores altamente subjetivos. De maneira geral, satisfação se refere ao nível de conforto que o usuário sente ao utilizar a interface e qual a aceitação como maneira de alcançar seus objetivos. A satisfação poder ser percebida por meio de análise qualitativa das atitudes, por exemplo, através da opinião do usuário, seja por meio de entrevistas ou mesmo comentários feitos durante a interação.
Esses conceitos e medidas devem ser entendidos como maneiras para melhorar a experiência do usuário durante seu contato como o site. A boa usabilidade ajuda a formar, ou manter, uma boa imagem diante dos usuários. Alcançar uma boa usabilidade é uma maneira de se destacar na multidão de serviços oferecidos na internet, viabilizar melhor o acesso ao conteúdo e se manter na briga para bater a concorrência.
Por Robson Santos – [Webinsider] clique veja matéria original
Arquitetura da Informação – SEO e A.I.
setembro 28th, 2009
De acordo com o iainstitute.org, Arquitetura da Informação é a definição da estrutura de ambientes de informação compartilhada e a arte e ciência de organizar e nomear websites, intranets, comunidades online e softwares para servir de apoio à usabilidade e à encontrabilidade. Encontrabilidade, um termo que não se vê muito, é a facilidade, ou nível/grau de dificuldade, que uma search engine terá para encontrar e navegar pelo seu site.
SEO, todos conhecemos, é o acrônimo para Search Engine Optimization, um conjunto de conceitos e técnicas que visam melhorar a qualidade de um site, a encontrabilidade e, extendendo, até mesmo a usabilidade. E como SEO se relaciona com AI?
SEO e Arquitetura da Informação
Basicamente, todo site recebe somente 2 tipos de visitantes:
- Pessoas; e
- Search engines (ou spiders, robôs de busca, etc.)
O casamento de SEO com AI visa melhorar a vida de todo mundo. Trabalhar a Arquitetura da Informação visa melhorar, para as pessoas, a usabilidade do site e, para spiders, aumentar o grau/facilidade de navegação e, por consequência, a indexação do site.
Especialmente no que diz respeito à encontrabilidade, alguns fatores fazem a diferença para facilitar a vida de search engines no seu site:
- Canonização de URLs
- Redirecionamentos
- Elementos de navegação
- Páginas 404 para páginas não encontradas
- Eliminar conteúdo duplicado
- Sitemaps
Aqui na Mestre SEO nós já escrevemos sobre todas essas informações, sugiro a visita em cada um dos links acima para um aprofundamento em cada tema. É importante garantir que esteja tudo em ordem no site, isso pode significar até mesmo um aumento de visitas, ou aumento de PageRank, já que trabalha, inclusive, nos links do site.
Canonização de URLs
Canonização de URLs é a escolha de uma única forma de acesso ao conteúdo. O exemplo principal é a escolha entre o acesso ao site por www.meusite.com.br ou meusite.com.br – a maioria dos sites permite o acesso das duas maneiras, o que é um problema, pois divide a força do site e gera conteúdo duplicado.
Redirecionamentos
Primeiro de tudo, é muito provável que todo redirecionamento que você precisar, será com código 301, o redirecionamento permanente. Isso porque o retorno de código 302 pode diminuir a frequência de indexação do site ou página. É necessária atenção para não fazer redirecionamentos sem fim ou não criar loopings (p1.html redireciona para p2.html que redireciona para p1.html).
Ao remover algum conteúdo, é importante também redirecionar o visitante para alguma página relacionada ou página de erro personalizada para não deixá-lo perdido, e para não deixar um robô de busca sem opções de navegação.
Elementos de Navegação
Tanto uma pessoa quanto um robô de busca vão se beneficiar do uso de elementos de navegação óbvios e simples. Um exemplo é o breadcrumb, mas também, entra na conta um menu organizado com links em HTML e, de preferência, com links em texto.
Páginas 404
Páginas personalizadas de erro 404 são de extrema importância: além de não deixar a search engine a ver navios, é possível ainda oferecer outros links para páginas similares, para o sitemap ou até mesmo para busca.
Conteúdo Duplicado
Conteúdo duplicado é um grande vilão dos sites. Organizar a estrutura de links e de URLs únicas para cada conteúdo evita conteúdo duplicado, que evita a distribuição de força para páginas iguais (que terá mais força sendo uma só), que pode melhorar o posicionamento do site nos resultados de busca. Vale lembrar o uso do canonical link element para ajudar nesta tarefa.
Sitemaps
Por fim, e não menos importante, o uso de sitemaps, tanto XML quanto HTML (a versão para usuários), são boas alternativas para ajudar o robô de busca a encontrar e indexar todas as páginas do seu site. Mais páginas indexadas, provavelmente resultará em mais visitas, uma vez que seja conteúdo de qualidade.
Texto retirado do Mestre SEO – Publicado por Frank Marcel em 23 de Abril 2009