
terça-feira, 28 de abril de 2009
Web Analytics: Além da implementação

segunda-feira, 27 de abril de 2009
Data da Páscoa, como calcular?
A apresentação mais interessante (e concisa) que achei para a data da Páscoa foi no material do prof. Kepler de Souza Oliveira Filho, do Departamento de Astronomia e Astrofísica, Instituto de Física, da UFRGS:
A páscoa judaica (Pesach), que ocorre 163 dias antes do início do ano judaico, foi instituída na epoca de Moisés, uma festa comemorativa feita a Deus em agradecimento à libertação do povo de Israel escravizado pelo Faraó, o rei do Egito. Esta data não é a mesma da Páscoa Juliana e Gregoriana.
O dia da Páscoa cristã, que marca a ressurreição de Cristo, de acordo com o decreto do papa Gregório XIII (Ugo Boncampagni, 1502-1585), Inter Gravissimas em 24/02/1582, seguindo o primeiro concílio de Nicéia de 325 d.C., convocado pelo imperador romano Constantino, é o primeiro domingo depois da Lua Cheia que ocorre em ou logo após 21 de março, data fixada para o equinócio de Primavera no hemisfério norte.
Entretanto, a data da Lua Cheia não é a real, mas a definida nas Tabelas Eclesiásticas, que, sem levar totalmente em conta o movimento complexo da Lua, podia ser calculada facilmente, e está próxima da lua real.
De acordo com essas regras, a Páscoa nunca acontece antes de 22 de março nem depois de 25 de abril.
Com base nas regras, foram desenvolvidos ao longo do tempo diversas técnicas e algoritmos para o Cálculo da Páscoa, ou Computus em inglês (calculation of the date of Easter), em cada ano do calendário cristão, em especial no Calendário Gregoriano utilizado no Brasil e muitos outros países latinos.
Relaciono a seguir as melhores referências que coletei a respeito:
Cálculo da Páscoa, verbete na Wikipédia em Português, apresentando tabela e algoritmos para cálculo da data da Páscoa em cada ano.
Computus, verbete na Wikipedia em inglês, apresentando história, teoria, métodos tabulares e algoritmos.
A Data da Páscoa, por prof. Kepler de Souza Oliveira Filho, Astronomia e Astrofísica, UFRGS; inclui uma tabela com as datas da Páscoa já calculadas para os anos de 1980 a 2024.
Como Calcular a Data do Domingo de Páscoa, por Arlindo Correa, 2001; inclui script que dado um ano, informa data da Páscoa, Carnaval, Dia da Ascensão, Pentecostes e Corpus Christi.
Cálculo do Dia da Páscoa, por prof. Roberto Cabral de Mello Borges, incluindo uma Tabela de dias da Páscoa, Carnaval e Corpus Christi de 1951 a 2078.
Cálculo do dia da Páscoa e de outras datas móveis, por José Luís Carneiro, 2009; inclui uma planilha para cálculo de datas móveis para baixar.
The Date of Easter e programa para cálculo de Datas da Quarta-feira de Cinzas (Ash Wednesday) e Domingo de Páscoa (Easter Sunday), em inglês, Naval Meteorology and Oceanography Command, Marinha dos Estados Unidos.
A Perpetual Easter and Passover Calculator, em inglês, por R.H. van Gent, Institute for History and Foundations of Mathematics and the Natural Sciences, 2003.
Dada a data da Páscoa, temos as seguintes celebrações, todas em dias da semana fixos:
Terça-feira de Carnaval ocorre 47 dias antes da Páscoa; celebração pagã;
Quarta-feira de Cinzas (Ash) ocorre 46 dias antes da Páscoa; início do período da Quaresma (Lent) [1], [2];
Quinta-feira da Semana Santa ocorre três dias antes da Páscoa; celebração da ultima ceia de Jesus Cristo com os doze apóstolos;
Domingo de Páscoa (Easter); celebração da Ressurreição de Jesus Cristo;
Domingo de Pentecostes ocorre no 50º dia desde a Páscoa;
Domingo da Santíssima Trindade é o domingo seguinte ao de Pentecostes;
Quinta-feira de Corpus Christi (Corpo de Deus) ocorre no 60 dias após a Páscoa; celebração da presença do corpo de Cristo na Eucaristia.
sexta-feira, 24 de abril de 2009
Garbage First Collector da Sun Elimina Amplamente a Baixa Latência/Alto Consumo
Postado por Charles Humble, traduzido por Ricardo Almeida em 24 Abr 2009 02:59 PM no InfoQ
O Garbage Collector da Sun chamado Garbage First (referenciado de G1) é o novo garbage collector de baixa latência planejado para substituir CMS no Hotspot da JVM. É um coletor estilo servidor, dirigido a máquinas multi-processamento com muita memória. Existem duas grandes diferenças entre CMS e G1. Primeiro que o G1 é um coletor com compactação. Compactação, um processo o qual a vida de objetos são movidas para espaços de memória livre no fim da pilha (heap) de modo que outros espaços tornam-se uma área contínua de memória livre, é importante em aplicações de execução longa porque é inevitável que a pilha irá se fragmentar no decorrer do tempo. G1 compacta suficientemente para evitar completamente o uso de listas livres de granularidade fina para alocação, o que simplifica consideravelmente partes do coletor e sobretudo elimina questões de potenciais fragmentações. Bem como a compactação, G1 oferece pausas de coleta mais previsíveis do que pode obter com o coletor CMS e permite usuários configurar as pausas do coletor. Essa determinística forte dá ao G1 algumas características de um coletor de Tempo Real (Real-Time) verdadeiro, porém não é fortemente Tempo Real, uma vez que fatores como agendamento do Sistema Operacional ainda significam que pausas não podem ser garantidas. Para o desenvolvedor entretanto consideravelmente mais fácil de usar do que produtos Java de Tempo Real desde que o código existente é capaz de ter performance melhorada sem necessitar de qualquer alteração em código. G1 usa algumas técnicas interessantes, baseadas na marcação global de informação e outras métricas, para priorizar regiões para coleta de acordo com a eficiência da Garbage Collector. Um artigo InfoQ anterior fornece mais detalhes técnicos.
Em um podcast recente,, James Gosling destacou a importância do G1 para certos tipos de aplicações Java de larga escala, semelhante a intercâmbios financeiros, que são caracterizados por grandes quantidades de dados vivos na pilha e considerável paralelismo no nível de thread, e são executados frequentemente em processadores multi-core:
"...o segredo profundo sobre muito dessas aplicações Java é que eles não usam banco de dados realmente. Ao invés de banco de dados eles usam muita RAM e empurram o garbage collector igual maluco porque eles não podem se dar ao luxo de tocar o disco sempre. Quando você está fazendo muitos, muitos milhares de transações por segundo, é bom manter tudo na RAM, usando tabelas hash, obtendo muitos núcleos focados nas transações na medida do possível, e geralmente ter grande questões sobre latência de operação.""
Gosling fala da diferênça entre consumo e determinismo. Tipicamente um garbage collector é otimizado para um ou outro. Um garbage collector otimizado para consumo é ideal para executar tarefas de segundo plano muito longas, onde pausas para garbage collector não são um problema para terminar a tarefa de segundo plano o mais rapidamente possível. Inversamente, se você está trabalhando em um sistema iterativo semelhante a uma aplicação web, então uma baixa latência do garbage collector é geralmente a melhor escolha. Gosling mostra o ponto que essas diferenças também existem em outras partes da JVM e que geralmente a JVM é otimizada para consumo. Realmente:
""Isso acontece todo lugar onde existe algoritmos que reorganizam algo. Então ter uma tabela hash - todos pensam que uma tabela hash tem tempo constante de inserção e tempo constante de remoção, o que é falso. O tempo de inserção é constante até ter que recolocá-lo no hash e depois uma insersão vai levar um bom tempo.""
Permitindo usuários especificar que o garbage collection não consuma mais que x ms de tempo, o G1 pode tentar manter pausas de collection como pequenos e não frequentes como for necessário para a aplicação, mas não tão lento como to diminuir consumo ou aumentar desnecessariamente a pegada. Dado que o garbage collector tem uma das áreas onde o ganho lento de latência é mais visível, o G1 deve oferecer benefícios significantes para desenvolvedores Java Enterprise. Está disponível no release do Java 6 update 14 e o time do Hotspot da Sun está extremamente vivo para ter feedback e bug reports dos que adotam cedo.
quinta-feira, 23 de abril de 2009
"QI" emprega 64% dos funcionários em TI
Segue a transcrição do artigo.
Estudo realizado pela Impacta Tecnologia mostra que um bom colega vale mais do que mil currículos

Ter um bom currículo é essencial. Estar cadastrado nas principais redes sociais profissionais, também. Assinar serviços de recrutamento online, idem. Mas o que mais ajuda um profissional de TI no Brasil a arrumar um emprego é ter um bom e influente colega. O popular QI - quem indica.
É a conclusão que dá para tirar de uma pesquisa realizada pelo Grupo Impacta Tecnologia – no Brasil, 64% das contratações que ocorrem no setor de TI são fruto de indicações de outros funcionários. Entre outras formas de recrutamento, a de buscar por colaboradores em sites especializados em bancos de currículo apareceu em segundo lugar, com 49% das respostas.
O estudo mostra também que os profissionais de tecnologia estão permanecendo por menos tempo nas empresas. Em 2003, a quantidade de profissionais nas copanhias com menos de três anos de casa era de 21%, relação que saltou para 50% na mesma pesquisa realizada em 2009.
Outro dado é referente à formação de equipes. Segundo a pesquisa, 19% dos times de TI têm de um a três anos, mas a maioria das equipes nas empresas foi formada há mais de cinco anos.
O levantamento realizado pela impacta fez um comparativo entre o ano de 2003 e 2009. Foram realizadas 100 entrevistas junto a 100 empresas de médio e grande porte, escolhidas aleatoriamente no país.
por Bruno Ferrari, de INFO Online
23 de abril de 2009
segunda-feira, 20 de abril de 2009
Java x .NET
Tem blogs que merecem sempre uma visita diária, um deles é o do meu amigo André Dourado. Dentre as últimas notícias publicadas por ele... selecionei esta:
Essa é uma das respostas do Márcio Tierno no grupo UML-FATEC, sobre a eterna discussão sobre qual a melhor plataforma de desenvolvimento: Java ou .NET.
Sei que esse assunto de quem é melhor Java x .NET é quase como discutir sobre religião. Mas o problema sobre produtividade no desenvolvimento de software é uma questão de foco, ou melhor, o problema não é tecnológico e sim estratégico.
“Um pouco de números para tentar dar um pouco de prumo a essa discussão:
1 - 80% dos negócios do mundo rodam em cima de programas COBOL. Nem Java nem .NET vão decidir o futuro da humanidade, portanto.
2 - Nunca vi um sistema que não pudesse ser implementado em qualquer linguagem que seja. Portanto, a discussão Java x .NET não se decide na esfera técnica.
3 - Produtividade - não é criando grids para acesso direto a tabelas que se mede produtividade, mas sim no tempo total que leva para uma idéia sair da cabeça do usuário de negócios até se transformar em um sistema rodando no ambiente de produção, testado, aprovado e homologado. Numa “competição” Java x .NET, é certo que ambas as tecnologias chegariam empatadas “na margem de erro” caso se considerasse todo o ciclo de vida de um sistema.
4- Ainda em produtividade, só de 15% a 20% do tempo é gasto efetivamente em implementação. O grosso do esforço é gasto em levantamento de requisitos e testes.
Por falar em produtividade, só 30% do tempo do programador é gasto em desenvolvimento de fato, em média. O resto é perdido em debugging ou reescrevendo requisitos que foram mal-entendidos (e mal-explicados, por conseguinte). Pare e pense na sua rotina diária e veja se vc discorda desses números.
Assim, 20% X 30% = 60% do tempo total de um projeto em desenvolvimento REAL. Supondo que uma das duas tecnologias fosse 50% MAIS PRODUTIVA do que a outra (e nenhuma delas o é), o impacto final seria de 3% sobre o tempo total do projeto. Quase indetectável.
Assim, o desafio proposto perde a validade em si. Até porque ninguém vai sair “convertido” de um evento desses. Agora, um desafio de ponta a ponta, num prazo de algumas semanas, por exemplo, esse sim teria valia. Mas já não seria mais um desafio Java x .NET, mas, talvez, um desafio MDA x AMD (tipo Together) x Agile (S. Ambler), por exemplo.
4 - Decisões estratégicas - Há uns 20 anos, mais ou menos , o Natural/ADABAS ganhou um grande mercado do COBOL, porque era muuuito mais produtivo e fácil de mexer. Hoje quem tem Natural/ADABAS quer morrer, porque a Software AG está cobrando os tubos (zilhões de dólares) pela renovação das licenças e a tecnologia é “imigrável”. Paralelo com .NET, proprietário como Natural/ADABAS. Erro estratégico.
Outro exemplo: há 30 anos, C prometia ser o que Java promete hoje. Se alguém algum dia teve um sistema de negócios escrito em C, então deve ter uma boa história de migração urgente para contar. Paralelo com Java, “assembleísta” como C. Outro erro estratégico.
Então, amigos, tecnologicamente falando, Java e .NET se equivalem.
Não consigo imaginar um sistema corporativo (que é o que interessa, afinal) que possa ser feito em um, mas não no outro. Ou que saia muito mais rápido em um do que no outro.
Portanto, o cerne da questão é estratégico, não tecnológico.
E todos os xiitas são gentilmente deixados de lado nessas discussões.
De minha parte, entre Java e .NET, fico com arquitetura de software, MDA e Governança de TI.
Na guerra entre as partes, prefiro vender a munição.
Márcio Tierno (mtierno.rm): é atualmente responsável por toda a divisão de testes funcionais da Inmetrics. Atua na área há 16 anos, tendo trabalhado em empresas como Compuware do Brasil, IBM, Rational Software, BCP Telecomunicações, entre outras. Cursou Ciência da Computação na Unicamp, é certificado ITIL Foundations e Rational Requirements Mngt. Marcio já prestou consultoria e ministrou dezenas de treinamentos em Ger. de Projetos, Requisitos e demais disciplinas de desenvolvimento para empresas como Serpro, Xerox, BankBoston, Banco Itaú, Banco Votorantim, Cargill, Porto Seguro e outras de grande porte, no Brasil e no exterior.
sexta-feira, 17 de abril de 2009
Um pouco dos ultimos 3 dias...
- As 10 + da Blogosfera Brasileira
- Estratégias de Transação Baseadas nos Modelos de Transação Java
- Físicos criam o relógio mais exato do mundo
- GlassFish Tools Bundle for Eclipse liberado
- Novo recurso do Gmail sugere destinatários
- Online Reputation Management
- Serviços offshore crescem 75% no Brasil
- TV digital terá Java como grande aliado
Carreira quente: analista de negócios em tecnologia
Sandra Siqueira, coordenadora de sistemas do hospital paulistano Sírio Libanês, acompanhou um projeto de nutrição no qual o analista de negócios acompanhou, por algum tempo, o dia-a-dia do setor, documentando e até filmando as atividades realizadas. A partir dessa experiência, o analista pôde entender qual era a dinâmica de trabalho e mapear suas necessidades para, então, desenvolver soluções.
“Neste caso, pudemos observar uma mobilização rápida de departamento de tecnologia no atendimento às necessidades da área. Os próprios nutricionistas se sentiram mais valorizados e comprometidos com o projeto que envolvia sua área. Consequentemente, o tempo de resposta foi menor no desenvolvimento”, afirma Sandra.
A profissional afirma que o analista de negócios não pode ser confundido com um gerente de projetos ou um gestor de relacionamento, apesar de precisar ter habilidades comuns a esses dois profissionais. “O expertise em gestão é muito importante, mas esse profissional está muito mais preocupado em ir ao núcleo da real necessidade do usuário do que em controlar o processo como um todo”, comenta.
Cláudio Kerber, líder de uma equipe de análise de negócios na Ionics, empresa de automação para o mercado de combustíveis, acredita que o bom profissional da área consegue enxergar além das necessidades declaradas do usuário. “É necessário questionar por que o cliente pede determinada solução e atingir um diagnóstico. Nem sempre o que ele está pedindo é o que ele realmente necessita”, diz Kerber.
Para Kerber, o profissional tem que ter excelente capacidade de síntese, pois interage com muita gente e precisa reunir idéias para chegar a uma conclusão. “Além disso, precisa saber priorizar as necessidades dos negócios”.
Kerber diz que o profissional pode ser nativo tanto de gestão quanto de tecnologia. “O profissional de TI tem um pragmatismo que pode ser muito útil para a equipe, ao passo que o de gestão sabe enxergar bem o negócio. O ideal é juntar os dois tipos em uma equipe de análise de negócios”, complementa.
quarta-feira, 15 de abril de 2009
Comunidade “Manifesto Ágil”
Segue a reprodução do post feito por ele em seu blog.

É bom comer gordura, beber vinho e fazer sexo?
Hoje, navegando na grande rede, achei um post "

Três assuntos interessantes… gordura, vinho e sexo!!!
Sobre a GORDURA:
No Japão, são consumidas poucas gorduras e o índice de ataques cardíacos é menor do que na Inglaterra e nos EUA;
Em compensação, na França se consome muitas gorduras e, ainda assim, o índice de ataques cardíacos é menor do que na Inglaterra e nos EUA;
Sobre o VINHO:
Na Índia, se bebe pouco vinho tinto e o índice de ataques cardíacos é menor do que na Inglaterra e nos EUA;
Em compensação, na Espanha se bebe muito vinho tinto e o índice de ataques cardíacos é menor do que na Inglaterra e nos EUA;
Sobre o SEXO:
Na Argélia, se transa muito pouco e o índice de ataques cardíacos é menor do que na Inglaterra e nos EUA;
Em compensação, no Brasil se transa muuuuuito e o índice de ataques cardíacos é menor do que na Inglaterra e nos EUA;
CONCLUSÃO:
Beba , coma e transe sem parar,
pois o que mata é falar inglês!
Eu já parei meu curso…
terça-feira, 14 de abril de 2009
Parkour é para os fracos
Catalogo de Patterns
Detalhando Design Patterns
- Nome - A identificação do Pattern é importante pois ele torna-se membro do vocabulário do projetista e de seus colegas.
- Problema - descreve quando aplicar o Pattern. Apresenta a classe de problemas em questão e seu contexto.
- Solução - descreve os elementos que fazem parte do design, seus relacionamentos, responsabilidades e colaborações.
- Conseqüências - os resultados e efeitos causados pela aplicação do Pattern.
- Criacional:Diz respeito ao processo de criação de um objeto;Ex: Builder - separa a construção de um objeto complexo de sua representação, desta maneira um mesmo processo pode ser utilizado para criar diferentes representações.
- Estrutural:Diz respeito a composição de objetos e classes;Ex: Composite - Compõe objetos em árvores de agregação (relacionamento parte-todo). O Composite permite que objetos agregados sejam tratados como um único objeto.
- Comportamental:Caracteriza o modo como classes e objetos interagem e compartilham responsabilidades.Ex: Iterator - Provê um modo de acesso a elementos de um agregado de objetos, seqüencialmente, sem exposição de estruturas internas.
segunda-feira, 13 de abril de 2009
Um pouco de Acessibilidade web...
Segundo a wikipedia Acessibilidade Web refere-se a prática de fazer websites que possam ser utilizados por todas as pessoas, sejam portadoras de deficiências ou não. Quando os sites são corretamente concebidos, desenvolvidos e editados, todos os usuários possam ter igual acesso à informação e funcionalidade.
As necessidades que a "Acessibilidade Web" pretende abordar incluem:
- Visual: Deficiências Visuais, incluindo cegueira, vários tipos comuns de baixa visão e baixa acuidade visual, vários tipos de daltonismo;
- Motora / Mobilidade: ex.: dificuldade ou impossibilidade de utilizar as mãos, incluindo tremores, lentidão muscular, perda ou baixo controle muscular e etc, devido a condições, tais como Doença de Parkinson, distrofia muscular, paralisia cerebral, acidente vascular cerebral;
- Auditivos: Surdez ou deficiência auditiva, incluindo indivíduos com pouca audição;
- Convulsões: Fotoepilepticos convulsão visual causada pelos efeitos estroboscópicos ou pisca-pisca.
- Cognitiva / Intelectual: Deficiência desenvolvimento , dificuldades de aprendizagem (dislexia, discalculia e etc), e deficiências cognitivas de várias origens, afetando memória, atenção, de desenvolvimento (maturidade) a resolução de problemas e lógica das competências e etc;
Navegando hoje, me deparei com este artigo da Lêda Spelta publicado na imasters.com.br, confira!
Os mitos na acessibilidade web
No meu trabalho com acessibilidade web, tenho me deparado com mitos que, por não terem suas verdades decifradas, são reproduzidos e compreendidos no seu sentido literal, o que tem prejudicado bastante o nosso progresso. Eles não aparecem como narrativas de estórias, mas como afirmações pseudocientíficas, que confundem a mente daqueles que ainda não adquiriram um profundo conhecimento do assunto.
Após sete anos de convivência com esses mitos, creio que chegou a hora de sistematizá-los e compartilhá-los com todos aqueles que se interessam pelo tema. Cada mito apresentado será, primeiramente, confrontado com a realidade objetiva, que é, como veremos, muito diferente do que o mito afirma. Em seguida, tentarei explicitar o que entendo ser a verdade oculta encerrada no mito. Neste caso, como a verdade é sempre um temor, será chamada de "temor oculto". Finalmente, tentarei oferecer uma resposta a esse temor, que será chamada de "esclarecimento".
O que é um mito?
Os mitos são narrativas (este é o sentido da palavra original grega), que são reproduzidas (imitadas) até se tornarem coletivas.
Aristóteles, em sua Poética, nos diz que "O imitar é congênito no homem... e os homens se comprazem no imitado." Os mitos não se baseiam na experiência empírica nem científica, baseiam-se na intuição. E aí está a sua força, pois a intuição encerra sempre uma verdade. Porém a verdade do mito não está aparente, precisa ser decifrada.
Quando, por exemplo, digo que determinada mulher é uma Atena, não quero dizer (como no mito da deusa) que ela não foi gerada no ventre de sua mãe, mas dentro da cabeça de seu pai, de onde saiu prontinha, com armadura e tudo! Estou querendo dizer que ela é uma mulher guerreira, racional e bastante identificada com o modo de pensar masculino.
A verdade de um mito, portanto, não é literal, é simbólica. É por este motivo que muitos o confundem com mentira, ilusão, lenda e fantasia. Eles são exatamente isto, se forem considerados no seu sentido literal.
Os mitos na atualidade
Uma característica dos mitos modernos é que, ao contrário dos mitos gregos ou indígenas, eles não se referem à totalidade da existência humana, mas a temas específicos, como a sensualidade, a juventude, o corpo saudável, o poder etc. E, como sua base inconsciente não está na razão e sim na emoção, eles são largamente utilizados na propaganda e na política.
Mito I - "Acessibilidade Web é só para deficientes visuais."
Realidade: Pessoas cegas ou com baixa visão são terrivelmente prejudicadas pela falta deacessibilidade, pois, na maioria das vezes, elas não têm outra forma de obter a informação, a não ser através da internet. Mas não são elas as únicas que necessitam de acessibilidade.
Acessibilidade web é para...
- ... Quem tem dificuldade para
- ver a tela,
- usar o mouse,
- usar o teclado,
- ler um texto,
- ouvir um som,
- navegar na internet;
- ... Quem usa um navegador diferente;
- ... Quem usa um equipamento muito antigo;
- ... Quem usa um equipamento muito moderno;
- ... Quem tem uma linha de transmissão muito lenta;
- ... Quem está num ambiente ou situação que limita alguns dos seus sentidos ou movimentos, ou que requer a sua atenção.
Enfim, acessibilidade web é para todos!
Temor oculto: "Imagina o trabalhão que vai dar, fazer acessibilidade para todo mundo!"
Esclarecimento: Quando seguimos uma diretriz de acessibilidade, estamos atendendo simultaneamente a vários tipos de necessidades. Por exemplo, atender a três tipos de deficiências não significa trabalho triplicado.
Note-se que este mito está tão profundamente arraigado em nossa cultura, a ponto de aparecer expressamente no Decreto 5296, o qual estabelece, em seu Artigo 47, que "No prazo de até doze meses a contar da data de publicação deste Decreto, será obrigatória a acessibilidade nos portais e sítios eletrônicos da administração pública na rede mundial de computadores (internet), para o uso das pessoas portadoras de deficiência visual, garantindo-lhes o pleno acesso às informações disponíveis."
Mito II - "Na prática, o número de usuários beneficiados com a acessibilidade é relativamente muito pequeno."
Realidade: A maioria das pessoas que conhecemos não tem nenhuma deficiência e nunca esteve em nenhuma das situações especiais descritas acima. Mas isso não quer dizer rigorosamente nada a respeito da quantidade dessas pessoas e situações. Por exemplo, quantos tailandeses você conhece que usam a internet? Será que você poderia concluir, então, que são muito poucos os tailandeses que usam a internet? Nossa visão da realidade é sempre distorcida, pois tendemos a nos aproximar e conhecer somente aquilo que nos é semelhante.
Temor oculto: "Esse negócio de acessibilidade é muito investimento para pouco retorno."
Esclarecimento: Quando tornamos o nosso site acessível, além de atingirmos os usuários da internet que não nos podiam acessar devido às barreiras encontradas, também estamos criando condições para que novas pessoas se animem a usar a internet; ou seja, estamos ampliando o nosso mercado. Além disso, estamos aumentando a visibilidade do site para os buscadores web, pois, assim como as pessoas cegas, eles também só conseguem ler o que está em texto.
Mito III - "Fazer um site acessível demora e custa caro."
Realidade: Geralmente, afirmações como esta são proferidas sem nenhuma avaliação prévia. Contudo, só podemos saber se o tempo e o custo do nosso projeto são adequados, se levarmos em conta os benefícios alcançados.
Temor oculto: "Não estarei empregando mal os recursos que tenho, ao fazer acessibilidade? Não vou ficar no prejuízo?"
Esclarecimento: Quebrar todas as escadas de um prédio para colocar rampas e todos os banheiros para torná-los acessíveis vai demandar um tempo e um custo adicionais; mas vai permitir o acesso por muito mais pessoas. Porém, se o prédio for projetado com rampas e banheiros acessíveis, o custo e o tempo de construção não serão maiores por isso. O mesmo acontece com os sites. Algumas adaptações são trabalhosas, mas o resultado vale a pena; e quando se trata de um novo projeto, o custo adicional geralmente não existe.
Mito IV - "É melhor fazer uma página especial para os deficientes visuais."
Realidade: Isto é melhor para quem? Os webdesigners terão trabalho dobrado, para criação e manutenção de duas páginas. Os deficientes visuais ficarão prejudicados, pois o que invariavelmente acaba acontecendo é que a página deles fica desatualizada. Sem falar naquelas páginas especiais, que já são projetadas com menos funcionalidades do que a das "pessoas normais". Além disso, o site continuará inacessível para todos os outros tipos de deficiências, necessidades ou situações especiais.
Temor oculto: "A gente não vai conseguir fazer uma página acessível, que seja tão bonita e funcional como a nossa."
Esclarecimento: A partir de 1998, com a promulgação da Section 508 (lei americana de acessibilidade), as grandes empresas de software começaram a investir em acessibilidade. Atualmente, os recursos de acessibilidade disponíveis já nos permitem criar sites bonitos, funcionais e acessíveis. Obviamente, para se obter um bom resultado, a técnica de acessibilidade, como qualquer outra, precisa ser aprendida.
Mito V - "Um site acessível a deficientes visuais não é bonito."
Realidade: Pessoas cegas não têm condições de usufruir da maioria dos atributos visuais de um site. Porém, os elementos que tornam um site esteticamente bonito não atrapalham as pessoas cegas, se forem criados dentro dos padrões de codificação, das diretrizes de acessibilidade e se a página tiver uma boa arquitetura de informação.
Temor oculto: "Só sei fazer sites bonitos usando tecnologias inacessíveis; de fato, não sei exatamente quais são os elementos visuais que atrapalham a acessibilidade. Por isso, quando tenho que fazer um site acessível, faço sempre o arroz com feijão."
Esclarecimento: Sites acessíveis a deficientes visuais podem ter imagens, fotos, vídeos, gráficos, etc, etc... Basta observar os padrões de codificação e as diretrizes de acessibilidade; e nenhuma delas proíbe essas coisas. Os testes com usuários, além de fazerem parte das boas práticas de um projeto, sempre ajudam a desmistificar essa questão.
Mito VI. - "Vamos por partes: primeiro fazemos o site, depois fazemos acessibilidade."
Realidade: Não dá para fazer tudo ao mesmo tempo, precisamos priorizar. Porém, inaugurar o prédio com escadas e depois quebrar tudo para colocar rampas não é priorização, é desperdício de tempo e recursos. E é exatamente isto que acontece com um site, quando deixamos a acessibilidade para depois. Vamos ter que refazer muita coisa que já poderia ter sido feita com acessibilidade, sem custo adicional.
Temor oculto: "Não vamos conseguir fazer um site acessível, com o tempo, os recursos e a equipe que temos."
Esclarecimento: Como acontece com qualquer tecnologia, geralmente o primeiro projeto acessível demanda um tempo e um custo maior, porque precisamos de capacitar a equipe. Mas isto acontece apenas no primeiro projeto, além de ser um bom investimento em termos de ampliação do público alvo.
Mito VII - "A gente sabe o que é bom para o usuário."
Realidade: A gente aprende muito sobre o usuário com a experiência. Mas a gente só aprende tudo sobre o usuário, se a gente for o próprio usuário; ainda assim, agente vai ser apenas um dos vários tipos de usuários possíveis, deixando de fora todos os outros grupos.
Temor oculto: "Não quero expor meu projeto às críticas do usuário."
Esclarecimento: Quanto mais cedo os usuários puderem dar seus "palpites" no projeto, menos alterações ele precisará depois e mais robusto ele será. Não tenha medo!
Um Grande Equívoco
Existe uma oitava assertiva, que não é exatamente um mito, nem se refere apenas à acessibilidade. Trata-se de uma convicção equivocada, proveniente da falta de conhecimento da repercussão da web, do seu impacto na vida das pessoas e na forma como a informação é veiculada nos dias de hoje. Apesar de não ser um mito, podemos detectá-la como um pensamento subjacente em quase todos os mitos descritos anteriormente. A assertiva é a seguinte:
"Meu site é direcionado a um público específico; ele não interessa a todos os grupos de usuários."
Para entendermos onde está o equívoco, precisamos analisar primeiro o que é "público específico" e o que são "grupos de usuários".
Normalmente, quando falamos que o nosso site se dirige a um público específico, estamos nos referindo ao conteúdo do site e estamos querendo dizer que tal conteúdo só tem interesse para uma determinada parcela do público em geral. Sabemos, por exemplo, que o público-alvo de um site de notícias, ou de um serviço público, é muito diferente do público-alvo de um site de tricot, ou de paleontologia. Contudo, isto é muito diferente do conceito de grupos de usuários, utilizado em acessibilidade e em usabilidade. Neste caso, estes grupos não se referem ao conteúdo da informação, mas às características de funcionalidade dos usuários. Muitas destas características foram descritas anteriormente, na análise do Mito I.
O equívoco acontece quando associamos grupos de interesses a grupos de funcionalidades. A experiência nos mostra que esta associação é muito mais tênue do que parece. Vejamos alguns exemplos:
- Um homem com baixa visão que entra no site de um fabricante de automóveis, para escolher um modelo para a sua mãe.
- Uma jovem surda que entra numa loja virtual de CDs, para escolher um presente para o seu namorado.
- Um menino de 11 anos que entra num site direcionado à terceira idade, para pegar uma informação para a sua avó.
- Uma estudante cega que entra numa livraria virtual, para comprar livros que serão escaneados por ela própria e lidos com o seu programa leitor de telas.
Portanto, quando restringimos o acesso do nosso site ao que julgamos serem as características do seu público alvo, estamos, na prática, usando a internet para limitar o nosso público, ao invés de ampliá-lo.
Veja o artigo original aqui!