quarta-feira, 25 de junho de 2008

Desenvolvimento e Resultado Final

Por fim, o protótipo do EasyTrader foi implementado.

Uma das primeiras dificuldades que tivemos no decorrer do desenvolvimento foi com o estilo de listas de opções que tínhamos. O Android provê, por padrão, um template de lista comum, sendo a visualização feita apenas com um label, enquanto as listas do EasyTrader são todas identificadas a partir de um ícone colorido ao lado esquerdo para identificar a função de cada uma quando estiver visualizando uma notificação, por exemplo.

Neste caso, foi preciso gastar um bom tempo de pesquisa para descobrir que era necessário definir uma sub-classe da classe principal, onde tínhamos que fazer o override de da função getView, responsável por definir o que é desenhado em cada item da função.

Isso feito, bastou montar a tela de menus, cujo resultado pode ser visto na seguinte tela:


Uma vez o estilo de menus definido e implementado, tratamos de adaptar a classe de adaptador do banco de dados do sample NoteEdit para atender as necessidades do nosso aplicativo, conforme o diagrama de entidades mostrado abaixo:


O próximo passo foi, então, montar uma interface para inserção de dados de ofertas e interesses, cujos printscreens são mostrados respectivamente:


Cadastro de Ofertas


Cadastro de Interesses

Os cadastros de ofertas e interesses funcionaram muito bem, e agora restava desenvolver a interface de gerenciamento das notificações que entravam no sistema, e aí que entra o maior problema encontrado no desenvolvimento do sistema.
Pela definição do projeto, o aplicativo receberia as notificações através de sinais wireless, que não foi possível simular neste emulador. Tal problema ocorreu devido à falta de documentação existente com relação ao componente BlueZ, o que exigiu de nós que criássemos um componente que simularia outros aparelhos se comunicando com o nosso. Assim ,foi possível receber aleatoriamente notificações de outras instâncias que identificavam prospectivos negócios a serem realizandos com nossa instância, gerando assim uma série de notificações, como podemos ver abaixo:


Note que para facilitar a vida do usuário, as notificações já lidas aparecem com background mais escuro e são levadas às ultimas posições da lista.

Ao clicar em uma das notificações, é possível ver os dados relativos à ela:



Se os dados da notificação de fato te interessam, é possível clicar em Contato e verificar os dados da pessoa que registrou essa notificação:


Uma vez que a verificação de notificações será provavelmente o caso de uso mais frequente no sistema, projetamos a tela de splash para notificar o usuário da existência ou não de novas notificações a serem visualizadas.


Tendo a parte funcional pronta, ainda foi necessária a implementação da seção de configurações, conforme figura abaixo:


Aqui, temos poucas porém importantes opções. As de enviar ofertas ou interesses permitem ao usuário definir se quer que as outras pessoas recebam suas ofertas e interesses, respectivamente. Tais opções são usadas em casos em que o anunciante não quer ser incomodado com pessoas procurando por ele, mas ainda assim quer responsividade pelo que está ofertando ou interessado.
A frequência de funcionamento define quantas vezes por minuto o sistema deve fazer uma varredura procurando por outras instâncias do EasyTrader. É uma importante opção que tem a ver com a durabilidade da bateria do aparelho.
Na última opção, o usuário define quais dados pessoais ele quer que sejam publicados juntamente com notificações geradas pelo seu aparelho que são registradas em outro.

Por fim, uma seção de ajuda sempre se faz necessária. A seção criada por nós é separada por tópicos, e explica o que é o EasyTrader, como proceder com os principais casos de uso e dá algumas dicas de como aumentar o volume de negócios usando o aparelho.
Neste link é possível fazer o download do código-fonte do sistema, juntamente com seus recursos.

Neste link é possível fazer o download de uma simples apresentação de slides sobre o sistema, e que é também o glossário dos termos utilizados ao longo de todo o projeto do sistema.

domingo, 11 de maio de 2008

Sincronizando

Este post tem como objetivo promover a sincronia do blog do grupo com as atividades sendo realizadas. Ao longo do semestre, o grupo teve sérias dificuldades de organização com relação a postagens no blog, devido a, principalmente, motivos profissionais. Tal situação teve, inclusive, uma baixa: o Júlio acabou tendo que trancar o semestre, por não estar conseguindo conciliar as atividades acadêmicas com as profissionais, devido a uma série de mudanças por quais passou. Desejamos a ele uma boa sorte nesta empreitada!

No nosso útilmo post, o EasyTrader era ainda uma idéia a ser discutida. Após conversas, o grupo decidiu por adotar este projeto, de fato, para a realização da matéria no semestre. Detalhes de como foi projetado podem ser visto ao longo das atividades descritas nos itens a seguir:

Documento de Visão

Para detalhar melhor quais são os objetivos do sistema projetado, desenvolvemos o documento de Visão disponível aqui.

Desenvolvimento de Personagem

Para desenvolver atividades de teste e pensar em cenários de uso para o documento, criamos o personagem Carlos Alberto, um estudante universitário, que pensamos que será um típico usuário do tipo de sistema que esttamos criando. Sua ficha pode ser vista clicando aqui.

Plano de Testes

A fim de testar a usabilidade do sistema conforme o plano proposto, desenvolvemos um plano de testes para a avaliação do mesmo. Pode ser visto clicando aqui.

Primeiro Modelo de Interação (Baixa Fidelidade)

Eis o nosso primeiro modelo de telas (baixa fidelidade):

E seu respectivo mapa de navegação:


Primeira Avaliação


Durante a primeira avaliação heurística pelo grupo 9, foram detectadas falhas de transição (como ausência de algumas telas) e também falhas como ausência de um item de ajuda (guia).
Dado o relatório entregue pelo grupo, o novo modelo de baixa fidelidade ficou desta forma:



E o respectivo mapa de navegação:



Primeiro Protótipo


A montagem do primeiro protótipo baseado nos modelos de baixa fidelidade foi feita utilizando-se de peças soltas de papel, que podem ser vistas nas imagens a seguir. As telas utilizadas no protótipo foram as necessárias para se realizar as seguintes práticas concreta: "Visulizar os resultados não lidos" e "Cadastrar um interesse por um sapato que custe no máximo 50 reais".



Teste com o protótipo


Durante o teste, foi pedido a um outro grupo que realizasse as práticas concretas descritas acima, utilizando o protótipo de papel construído pelo grupo. O teste pode ser visto no filme abaixo:



Durante os testes, os voluntários identificaram falhas de navegação (não existia a opção de sair do programa a partir de uma tela intermediária) e também a respeito da "chamatividade" dos botões que lançavam os menus, que estavam baixos. Com relação ao primeiro item, vale lembrar que na grande maioria dos aplicativos, o botão de desligar um chamada é geralmente usado para sair do programa a partir de qualquer ponto, e o nosso não é diferente.

Nova versão de telas


A partir dos resultados do teste com o protótipo, fizemos um novo modelo de baixa fidelidade de interação com usuário. As telas são mostradas abaixo:


E seu respectivo mapa de navegação:


A prŕoxima etapa é, a partir deste novo modelo, fazer as modificações necessárias no protótipo, a fim de realizar um novo teste.

segunda-feira, 14 de abril de 2008

Retomando as atividades...

Devido à problemas pessoais e profissionais dos integrantes do grupo nas duas últimas semanas, as atividades no que dizem respeito ao projeto ficaram congeladas por algum tempo, e agora as estamos retomando.

Durante esse tempo, porém, foi estudada a viabilidade técnica da aplicação no que diz respeito à utilização da tecnologia Bluetooth. Aparentemente, nos dispositivos um pouco mais antigos, de fato deixar o sinal ligado o tempo todo consumiria muita bateria, o que parece já não acontecer mais nos dispositivos mais novos.
Porém, o que pode ser feito é deixar a frequência de utilização do sinal customizável. Assim, o sinal pode ficar ligado o tempo todo, pode fazer uma varredura a cada 10 segundos, 5 minutos, e assim vai, adaptando-se às restrições do aparelho do cliente específico.

No que diz respeito à utilização desta tecnologia na plataforma Android, existe de fato uma API de utilização dos devices bluetooth (org.bluez), no entanto ela é muito mal documentada, o que está exigindo um certo "hacking". Estávamos tentando desenvolver algo concreto utilizando isso antes de começar de fato a documentar o projeto pelas atividades propostas em aula, porém isso não parece que vai sair tão facilmente, então vamos preparar a documentação assumindo que vamos conseguir ter um protótipo funcional em breve.

sexta-feira, 14 de março de 2008

Proposta de problema e aplicação

O cálculo do tempo gasto com as diversas atividades realizadas por um colaborador de uma empresa é uma medida essencial para avaliar os processos da empresa e o colaborador. Atualmente o meio mais comum de fazer isso é através do preenchimento de planilhas.

Porém, o uso de planilhas gera dados imprecisos, uma vez que estas normalmente são preenchidas no final do expediente com uma "soma" aproximada do tempo gasto naquela atividade. O uso de planilhas mais detalhadas é trabalhoso e consome tempo e atenção dos colaboradores, implicando em descontentamento dos mesmos e perda de recursos.

Existe ainda o problema de anotar o tempo gasto em tarefas feitas longe do computador, o qual deve ser anotado manualmente e depois reportado nas "planilhas".

O software proposto é um sistema que auxilie na anotação do trabalho gasto em atividades. O hardware de apoio proposto é um celular (que pode ser adquirido facilmente e carregado). A idéia é que seja possível ao software do celular interagir com diferentes tipos de sistemas (Microsoft Project, Tracker, Planilhas Excel) tanto para saber quais tarefas devem ser realizadas, quanto para reportar o trabalho realizado nelas.

A questão da interface é essencial, de maneira a minimizar o esforço para anotar corretamente o tempo gasto. Sendo assim, o software deve minimizar a necessidade de digitação, cliques e deve ser simples parar e recomeçar o cronômetro ou trocar de tarefa.

Um aspecto interessante é a possibilidade de integração com outros softwares da plataforma, como, por exemplo, correção ortográfica e gramatical, iTap (para os aparelhos que não possuem teclado), gravação (para gravar anotações ao invés de digitá-las) e possivelmente reconhecimento de voz (para escrever o que foi gravado, embora isso provavelmente não devesse rodar no celular).

Bem, essa é a aplicação, esse é o problema. Vale ressaltar que esse é um problema real encontrado em minha empresa.