Confesso que até há poucos tempo atrás eu estava desesperado levemente preocupado com o meu tema de mestrado. Afinal, não conseguia definir um tema apropriado para minha pesquisa.

Decidir ir para um tema que chamou a atenção: Sistemas de Recomendação. O que seria isso?

Sistemas de Recomendação permitem fazer sugestões aos usuários sobre itens ou produtos, oferecendo ao usuário algo compatível com o seu perfil e assim, uma recomendação no meio de vários itens. Acho que o exemplo mais conhecido é o da Amazon que sugere livros próximos aos que estamos procurando durante a navegação.

Nos próximos posts vou falando um pouco sobre cada tipo de Sistema de Recomendação e sobre a bibliografia lida. Aproveito esses posts para escrever o primeiro capítulo da dissertação.

Até mais!

Porém, não é isso que ocorre, a grande maioria dos artigos científicos não são descobertas que vão mudar a humanidade e sim comparações de técnicas conhecidas aplicadas à certos problemas ou sugestão de melhorias em determinadas técnicas.

Entretanto, o meu objetivo é apresentar o porque profissionais deveriam sempre estar atenados com o surge de pesquisas na sua área. Por definição, matemáticos, físicos, químicos e biólogos sempre estão nesse meio, pois o trabalho deles depende disso. Mas eu digo os profissionais como os da área de medicina.

Um médico vai a um congresso de sua especialidade pelo menos uma vez por ano,  por quê? Ele precisa se atualizar sempre! Imagina só você sendo tratado com um medicamento ou técnica da época da formação do médico (mas supor 30 anos atrás) sendo que existem tratamentos novos.

Vejo que muitas empresas de TI usam técnicas de 30 anos atrás, sendo que há novíssimas que são direcionadas aos problemas atuais. O profissional de TI foca muito na sua técnica atual que até torna uma religião (como admiradores de Java, MySQL, Linux).

E até artigos podem conter uma inovação que pode virar um novo negócio. Vamos para um exemplo:

Hoje tudo mundo saber que banco de dados é a coisa mais banal do mundo com as suas buscas usando a linguagem SQL. Mas acredite, tudo isso não existia até o artigo A  Relational Model of Data  for Large  Shared  Data  Banks  de E. F. Codd da IBM (pode ser encontrado aqui). Lary Ellison inspirado nesse artigo, só fundou a Oracle com o seu banco de dados e hoje acabou de comprar a SUN que é uma empresa também baseada em inovações.

Ou seja, pesquisa não é só algo teórico sem sentido (e infelizmente muitos acham que é inútil), muitas vezes é a resposta para um problema simples que você tem que não pode ser resolvido pelos meios usuais.

Inovar é bom, você não precisa ser o cientista maluco, é só acompanhar os artigos de algum assunto que você gosta que estará muito a frente da grande maioria das pessoas e pode propor soluções realmente inovadoras.

Ao mexer num software interessante, você clica em um botão e espera, espera, espera…. logo vai pensando: Será que travou? Clico de novo? Fecho o software? Ctrl+Alt+Del? kill process? E de repende a operação é executada. Com certeza esse software tem um problema de resposta.

Antes de tudo vamos falar sobre o tempo. Para não ser muito filosófico, falarei sobre o tempo do relógio e o tempo percebido.

O tempo do relógio é o tempo absoluto: 2 minutos, 1 hora, 4 segundos… esse tempo é absoluto e medido por meios físicos. Óbviamente quando mais rápido um software executar uma tarefa melhor .

O tempo percebido é quando tempo alguma pessoa sente que demorou um evento. É totalmente relativo ao evento e à pessoa. Vamos simplificar a medida apenas com os valores “rápido” e “devagar“. Por exemplo, você passar o dia inteiro com a pessoa que você ama, na sua cabeça o dia passou muito rápido. Mas ficar esperando 1 hora alguém chegar, o evento aconteceu muito devagar. A melhor definição de software lento que eu vi de um usuário foi que o uso do software era “um suicídio” .

Nesse sentido, a resposta do software é muito importante diminuir o tempo percebido de uma tarefa. Como? No livro Gui Bloompers, dá umas dicas baseado na percepção humana para tempos absolutos para respostas:

• 0.1 segundos : Esse é  tempo de causa-e-efeito da percepção humana. Por exemplo, se algum objeto vier em sua direção, você irá demorar aproximadamente 0.1 segundo para iniciar a reação de defesa. Para UX, deve ser a resposta para as ações simples, como a indicação que um botão foi clicado ou uma caixa de diálogo apareça.

• 1 segundo: Esse é o espaço de tempo na mudança de um interlocutor de uma conversa. É o tempo que você processa a informação que uma pessoa de passou e começa a responder. Logo, uma tarefa simples é ideal que demore em torno de um segundo, como a validação de um cadastro.

• 10 segundos: Esse é o tempo limite que o ser humano se concentra numa espera de uma resposta. Depois disso a concentração é perdida. Por isso que um processamento complexo tem que dar respostas em 10 e 10 segundos, como um processamento muito pesado (atualizar a barra de progresso). Depois de 10 segundos sem resposta, o usuário vai achar que o software está com bug ou morreu de vez e pode tentar reexecutar a tarefa ou fechar o software.

Logo, uma tarefa demorada, é muito importante que avisamos ao usuário que tal operação vai demorar mas que o software está trabalhando no momento. Se avisar em quanto tempo irá terminar a tarefa melhor ainda.

Um detalhe muito importante também levantado no livro Gui Bloompers é o fato que desenvolvedores têm computadores melhores que os usuários reais. Em casa ou nas empresas de TI o desenvolvedor tem uma máquina parruda, pois ter programas servidores, IDES e o processo de compilação consomem muito recurso, mas o usuário comum tem muitas vezes computadores medíocres, telas minúsculas e conexões lentas. Portanto, é muito importante testar a resposta do software no ambiente real e sempre avise que a tarefa pode demorar!

Finalizando, sempre dê um enfoque maior ao tempo percebido do que o tempo real em software que o foco de uso é o usuário, se ele acha que o seu software é lento ou é devagar , ele com certeza vai perder a paciência! Faça-o perceber que é rápido que o usuário não irá reclamar de performance.

Seu software agora vai além das terras tupiniquins e começa a atingir outros países. Aí vem um grande problema: o que devemos considerar para internacionalizar um software?

Ah é só traduzir o textos do programa e sucesso! É meu amigo, não é tão simples assim… Vou levantar alguns pontos para serem pensados em um software internacional:

• Línguas: Quais as línguas seu software irá atingir? Além disso, quais países? Um software usável é um software bem escrito na língua local, além, disso vale lembrar que o Português de Portugal e do Brasil é bem diferente, logo, tem que considerar como línguas diferentes.
• Embromation não vale: Sempre que puder tenha algum nativo ou fluente que traduza a língua de destino. Muitos termos não têm tradução trivial ou o termo é muito ligado a uma área especialista, como por exemplo: como é pessoa jurídica em inglês?
• Suporte a multilínguas: Seu cliente vai trabalhar com o software com 2 línguas ao mesmo tempo? Logo, devemos ligar o usuário á uma língua de preferência. Imagine o exemplo do Canadá em que os habitantes de certas regiões falam Inglês e de outras falam Francês. Ou um caso mais louco que seria suportar parte da União Europeia.
• Charsets: Seu software tem suporte a charsets para vários alfabetos? Isso é crucial para integração com sistemas de alfabeto cirílico ou mandarim.
• Suporte a multimoeda: Se o software trabalha em vários países e com dinheiro, como suportará a moeda de cada país? Pense que é importante o conceito ver conversão entre moedas e consolidação em uma só (geralmente o Dólar é a escolha padrão)
• Data e hora: Outro conceito muito interessante é o formato de data e hora. No Brasil, normalmente a data é representada na forma D/M/A, mas nos Estados Unidos o formato é M/D/A. Além disso, a hora no Brasil é representada de 0 a 23 horas, mas nos EUA é de 0 às 12horas com AM e PM.
• Fuso horário: Pensou no fuso horário da aplicação? Imagine a seguinte situação: Um operador no Brasil aciona uma ação em um software que está hospedado na França que vai ter uma ação sobre um sistema na Rússia. Qual o horário da execução da tarefa: do operador no Brasil, do servidor na França ou do sistema na Rússia?
• Verificar as telas em outras línguas: Uma expressão em mandarim pode ocupar metade de espaço que em português ou uma expressão em alemão pode ocupar o dobro que em português. Qual o problema? Se o layout do seu software depender muito dos textos, é sempre importante verificar se há quebras de linha ou layout fora do padrão quando for traduzido.
• Sistema de medidas: O sistema internacional de medidas define umas medidas padrão como metro e litro, mas alguns países usam medidas diferentes como polegada, milhas e galão. Por algum esquecimento de ter conversões ou adotar um mesmo padrão, a NASA já perdeu uma nave. Seu sistema vai ter um sistema de medidas no SI ou no padrão do país? Vai ter um conversor?

A minha principal dica depois de todos esses pontos é tenta simplificar esse problema ao máximo, se não gastará mais tempo na internacionalização do que na função principal do software.

Para quem tem dificuldade para ter inspirações nessa área, recomendo verificar as “Configurações Regionais” do MS Windows, lá são abordados muitos pontos e o usuário pode configurar o sistema conforme a sua necessidade.

http://globonews.globo.com/Jornalismo/GN/0,,MUL1521261-17665-315,00.html

Você prefere investir 1 milhão em pesquisa ou em celebridade? A Clarins, uma das maiores indústrias de cosméticos do mundo decide investir em pesquisa.

Aqui eu vejo um ato corajoso e importante em uma empresa: agradar um cliente pela qualidade do produto do que tentar vender um sonho ou uma expectativa.

Quando uma empresa decide pela qualidade do produto, os ganhos não são imediatos, pois tem que por um tijolo por dia e muitas vezes é preciso refazer tudo. Porém, constrói uma base sólida e conhecimento agregado.

Ao investir em propaganda foca-se no imediato, ainda mais se põe o jogador de futebol ou a atriz do momento. Com certeza as pessoas na ilusão de seguir o seu ídolo vão comprar ou pelo menos experimentar o tal produto. Temos problema que o produto fica associado à imagem da celebridade o que pode ser ruim especialmente quando o ídolo cai em desgraça como o que aconteceu com o Tiger Woods.

Ao investir em pesquisa, não temos o garoto bonito na TV (na verdade os geeks dificilmente se preocupam com a beleza como as celebridade ), mas temos um produto estudado, testado e muitas vezes com tecnologia à frente dos concorrentes. Se contar nas patentes que a empresa gera sobre o novo produto desenvolvido.

Não que propagada não seja necessária, nesta mesma matéria mostra que a Clarins investe muito dinheiro em amostras grátis cujo objetivo é fazer o consumidor testar o produto e fidelizá-lo. Muito melhor investir 1 milhão também nisso do que numa celebridade não acham?

Infelizmente, vejo que isso é uma realidade distante, ainda mais em países como o Brasil cuja a cultura da pesquisa é inexistente dentro das empresas. Sempre estamos correndo atrás e imitando o pessoal de fora. Quando iremos inovar?

Qual desenvolvedor nunca ficou bravo com um cliente que não sabia operar no sistema que foi desenvolvido para ele? _o/

Se você um dia pensou nisso, assim como eu já pensei, mostra que caímos em um dos mais graves defeitos do desenvolvedor de software: a arrogância de achar que você sabe tudo sobre computação. Eu acredito que o desenvolvedor deve ser o especialista no que faz, mas também sabe o que o cliente faz?

Muitas vezes acreditamos que o usuário deve fazer o trabalho dele do nosso jeito (via nosso software)  quando na verdade o nosso software tem que resolver o problema dele! Vamos para um exemplo claro:  Quem nunca pegou algum aparelho ou brinquedo e ficou mexendo durante horas e depois descobriu que funcionava de um jeito totalmente diferente? É exatamente assim que o usuário se sente: você enganou o seu conhecimento especialista e o seu senso-comum.

O bom arquiteto da solução faz um bom modelo conceitual antes e a grande sacada do modelo conceitual é ser uma representação do modal conceitual que o cliente acha que o negócio dele funciona. Chame as coisas pelo nome que elas realmente têm no mundo real. Por exemplo, no mundo real nunca temos o tal de usuário e sim, consumidor, operador, leitor de um artigo, escritor de um artigo. Utilize o ambiente especialista para dar o nome às cosias

Mas e se eu não soube exatamente como o usuário trabalha? Apele para o senso-comum! Vamos para um exemplo: algum comando para parar uma operação ou um alerta de perigo é indicado o uso de cor vermelha (nos lembra fogo, sangue, semáforo).

Se cairmos no caso em que o usuário não sabe intuitivamente como operar o sistema, é porque você não está usando o modelo conceitual e nem o senso comum para indicá-lo como fazer a operação.

Acredite sempre que as pessoas preferem coisas simples em que elas dominam do que coisas complexas que tentam dominá-las.

Até mais

UI-Patterns : Contém vários padrões de interface com o usuário e em que momento é ideial usá-los

Experiência do usuário (Locaweb) : Blogue de UX da Locaweb

Quince : Contém vários padrões de UX classficados por função

Alguém conhece outros? Só comentar!

venho com um tema muito interessante para a produção de software como produtos que é a Interface Gráfica, ou a famosa GUI (Graphical User Interface). Nesse sentido, há duas grandes áreas que é Arte gráfica e a User Experience (UX).

Na minha opinião, a interface gráfica é tão importante quanto as regras de negócio da aplicação, pois, é a face do produto para o usuário. Interfaces ruins resultam em produtos ruins na visão do usuário, afinal, se eu não consigo fazer a minha tarefa, então para quê eu uso este software?

Vamos quebrar a produção de interface gráfica em 2 partes que são muito diferentes entre si: o Design e a User Experience. Os maiores mitos que é usado é que ambas as áreas são iguais e que o mesmo profissional pode dar conta de tudo, vamos ver que isso não é bem assim.

O Design do produto trabalha com a arte gráfica e o conforto visual. Normalmente é feito por designers que usam ferramentas de editoração gráfica como Photoshop, GIMP, InkScape, Corel Draw, entre outros. Um exemplo disso é o esquema de cores do site em que o designer escolhe as cores que são “próximas” e causam um conforto visual. Azul e amarelo é um contra exemplo de como isso deve ser evitado.

Já o analista de UX já é um profissional que se preocupa em como o usuário vai interagir com o software. Normalmente tem que estar alinhado com os desenvolvedores e as regras de negócio do produto. Um exemplo é de como deve ser os botões, nome de cada botão e a função que devem exercer. Normalmente usa ferramentas de prototipagem de telas como o Visio, Axure, ou mesmo a boa e velha folha de papel.

Mas as áreas não têm intersecção? Claro que têm, por isso que muitos profissionais fazem as duas coisas ao mesmo tempo. Porém se a gente diferenciá-las no ponto certo, a produção da interface gráfica supera as expectativas.

Vou abordar mais esses temas nos próximos posts. Até mais!

No artigo anterior eu falei de como configuração pode ajudar a ter um software compatível com várias funcionalidades diferentes. Entretanto, nem sempre é possível prever quais são essas funcionalidades ou se realmente elas vão ser necessárias e nesse ponto que entra o segundo artigo: Extensibilidade.

O que seria um produto extensível? É um produto no qual eu posso adicionar novos componentes que não pertencem ao produto original. Vamos voltar ao velho e bom exemplo dos carros:

Vamos pegar um velho e útil popular 1.0 como um Gol da VW. O modelo básico do carro não contém sistema de som e player de CD/MP3 por padrão, mas tem espaço para por o player e caixas de som e assim, o produto carro é extensível para o caso de aparelhos de som. Essa analogia é muito interessante, pois, motorista põe o sistema de som que atende a sua necessidade que pode ser ouvir o rádio quando vai ao trabalho ou ter um poderoso sistema de som para passeio.

Aqui temos outro ponto importante da extensibilidade: as funcionalidades adicionadas são compatíveis com a necessidade do cliente.

Indo para o lado de software, os maiores exemplos que dou para softwares extensíveis são os navegadores Mozilla Firefox e Google Chrome. Quem nunca ousou um add-on para poder tuitar ou ter alguma facilidade de navegação? Percebam que os add-ons do Firefox ou do Chrome são mantidos por pessoas fora do projeto principal do navegador e por ventura um add-on é são importante que é incorporado no produto.

Todo produto precisa de extensão? Depende. Se seu produto vai para um para um nicho de mercado nos quais os clientes têm muitas regras de negócio muito diferentes entre si, seria bem inteligente deixar pontos de extensão no produto. Exemplo: vamos imagina uma funcionalidade bem comum como cadastro de clientes. O momento de salvar um novo cliente é um bom momento para ter um ponto de extensão e chamar as funcionalidades customizadas e chamar um módulo para fazer validações, como uma consulta se o novo cliente dele tem nome do SPC, telefone está no Procon para não receber telemarketing, etc. A extensão deve fazer todo esse trabalho.

Qual a vantagem de se fazer desse modo ao invés de criar uma versão especial para o cliente? Imagine que o produto principal precisa de alguma correção de bugs ou sofre uma atualização. Teríamos que atualizar as 2 versões: a do produto principal e a do cliente o que seria muito custoso. Dessa outra forma, precisamos mexer em apenas 1 código e o risco de incompatibilidade do produto aplicado com o cliente é muito menor.

Até a próxima!

Primeiro, começo com uma citação do Steve Jobs:

“A lot of times, people don’t know what they want until you show it to them.”

Segundo, ponho a seguinte situação: Você faz aquele levantamento de requisitos bonitinho, desenha as telas e codifica. Ao apresentar aquele software bem feito ao interessado, ele diz: “Poxa, ficou legal, mas dá para mudar isto ou aquilo?” ou “Não era bem isso que eu queria”. Obviamente, você fica bem p. da vida chateado: “Poxa, mas por que você não me explicou direito?”

É meu amigos, muitas vezes nem o cliente ou o interessado sabe exatamente o que ele quer e você DEVE resolver os problemas dele.

Como resolver isso? Não há solução mágica, mas podemos amenizar tudo isso mostrando uma prévia ao interessado. Isso é uma prática muito bem difundida em técnicas de Desenvolvimento Ágil. Mas sofware como produto, é muito caro, desenvolver algo e ficar mostrando ao interessado e indo corrigir, ainda mais porque o cliente não existe ainda =D. Logo, você tem que chutar estimar muito bem baseado em casos antigos e que o seria interessado aos clientes.

Como? Ao levantar os requisitos, veja o seu público-alvo: no caso de produtos, normalmente são as pessoas relacionadas à Vendas, Pré-vendas, Pós-vendas e Marketing. Eles querem a cara dos produtos que normalmente são um descritivo das funcionalidades e os protótipos de tela. Ganhe a confiança deles, mostre o que vai ser o produto e eles sairão sabendo o que vai ser lançado e como vai funcionar antes de ter o produto. Aí temos tempo suficiente para discutir e corrigir as diferenças do entendimento.

Aproveite e também converse com o pessoal de projetos. Eles conhecem bem o dia-a-dia da implantação dos produtos e customizações, e assim, podem dar um rumo como melhorar tecnicamente.

Com isso, evitamos surpresas quando o produto for lançado, como funcionalidades não pedidas ou pior, funcionalidades pedidas, mas não feitas.