domingo, 22 de junho de 2008

Cores da interface

Uma coisa interessante ocorreu com o decorrer em paralelo do desenvolvimento do projeto e das aulas de interface.

Inicialmente, o menu principal do projeto do bHappy estava definido para ser assim, como segue a imagem:


Aqui seguem 4 telas de menu. A primeira (esquerda, acima) é o menu principal, onde o usuário tem acesso pela primeira vez quando loga no sistema, antes de fazer o login. As outras, o menu interno, acessado após o usuário fazer o login no sistema. As duas diferem em pouco, mas gostaria que fosse frizado o botão que está presente no menu inicial pré-login mas ausente no interno: o botão de login! (por motivos óbvios).

Toda a interface estava definida (menos o botão de amigos, com um homem e uma mulher junto) para ser feita em azul, verde e laranja. Houve que, após a aula de acessibilidade e daltonismo, decidimos passar os filtros para os três tipos de daltonismo suportados pela página (afinal, NADA impede ou atrapalha a presença de um daltonico em uma mesa de um HappyHour, o que os torna parte integrante do público alvo de nosso sistema). O resultado foi interessante:


Vamos ver um a um. No primeiro, o 'espelho' da fechadura do botão login quase desapareceu, uma vez que o 'laranja se transformou em dourado' e o bonequinho verde no botão 'perfil', quem diria, também ficou dourado e quase sumiu! No segundo, foi a vez do telhado do botão estabelecimento se confundir com o laranja do botão selecionado, e observou-se uma mescla entre o azul e o verda, não observada antes em nenhum outro caso de daltonismo. No terceiro, mais uma vez, o botão de 'perfil' teve seu boneco verde confundido com o fundo laranja de botão com foco, ocorrendo o mesmo com o telhado da casa.

Observando ainda: as cores preto e branco praticamente mantiveram sua tonalidade. O contraste entre as duas parece 'inabalável', independente do tipo de daltonismo. O azul foi a cor que mais se manteve estável nos testes.

Com estes dados, decidimos que um conjunto de cores simples, mas que apresentava boa acessibilidade, seria azul, preto, branco e o laranja do botão em foco. O menu reformulado segue abaixo:

...as visões daltônicas o enxergam como...


O problema da confusão do verde com o amarelo e laranja foi resolvido, mas ainda não tratamos o caso da cor vermelha, presente no telhado da casa.

Independente da cor vermelha, aprendemos uma árdua lição: fazer primeiro e pensar em acessibilidade depois é simplesmente desperdício de mão de obra. Qualquer coisa pode sair errado se não aplicarmos um planejamento mais refinado e que não esteja presente no cotidiano nosso que não temos necessidades especiais (não sei se este termo pareceu ofencivo ou, de alguma forma, depreciativo, mas não sou habil com palavras e não imaginei expressão melhor). Qualquer coisa mesmo: quem imaginaria que o verder se confundiria com... LARANJA!?

sexta-feira, 6 de junho de 2008

Status atual

Bom, gostaria apenas de formalizar que 40% da interface do Android já esta concluída para a apresentação. Mais para frente, postaremos algumas imagens do mesmo.

segunda-feira, 26 de maio de 2008

Projeto de Interfaces - Prototipagem em Papel

Partindo do planejamento do diagrama de navegação
iniciamos a fase de projeto do design da interface de interação com o
usuário.
Em sala de aula, iniciamos a fase de prototipagem rápida em papel
do design das telas do aplicativo.
No link abaixo, encotram-se exemplos dos protótipos elaborados, juntamente com
especificações e diretrizes que foram seguidas para elaboraçao do design e
posicinamento dos itens de interface.


http://www.students.ic.unicamp.br/~ra060639/files/telas_rascunho.pdf

quinta-feira, 22 de maio de 2008

Mapa de Navegação


Buscando apresentar uma relação entre as funcionalidades do
sistema foi elaborado um diagrama contendo o mapa de
navegação do sistema.
Esse expõe as ligações as ligações ou caminhos de acesso,
que poderão ser tomados pelos usuários para acessar 
determinadas ferramentas que o aplicativo oferece.


Durante a elaboração desse mapa, buscamos avaliar quais características
do sistema seriam importantes, afim merecerem destaque. 
Para realizar essa tarefa, primeiramente dividimos as funcionalidades
do sistema em grupos vinculados a atividade que que seriam oferecidas
aos usuário.

Relacionadas ao usuário
- Login
- Cadastro
- Perfil

Relacionadas ao amigos
- Listagem de amigos
- Inclusão de amigos
- Importar contatos do celular

Relacionadas aos estabelecimentos
- Consulta/Listagem de estabelecimentos
- Visualização dos dados de localização/contato
- Visualização de informação sobre exibição/cardápio
- Marcar interesse em ir ao estabelecimento
- Convidar amigos para ir ao estabelecimento

A partir disso, podemos ramificar as ligações:
-> partindo do tela inicial buscamos inserir as tarefas mais comuns
para os usuário:
 - Primeiramete, dar um caminho ágil para realizar o login do usuário
e entrar no sistema.
 - Também previmos que usuário poderiam querer utilizar certas
funcionalidades do sistema antes de se registrar. Como a principal
atividade que os clientes poderiam realizar seria procurar
estabelecimentos com as características que lhe interessassem para
poderem marcar encontros, obiviamente deixar livre a consulta
sem ter que se cadastrar é um atrativo para os usuários validarem
as funcionalidades do sistema, podendo então se cadastrar ao 
expressar seu interesse.

   Após logar-se o usuário teria acesso a tarefas mais comuns de
seu atividade ou de administração do sistema.
 - Acesso as configurações
 - Perfil do usuário
 - Listagem de amigos
 - Consulta de estabelecimentos
 - Agenda (com encontros marcados)

Após entrar em uma dessas subtarefas, estariam disponíveis
sub atividades relacionadas aos temas mencionados anteriomente.


sexta-feira, 16 de maio de 2008

Reestruturação do Banco de Dados

Após longo tempo sem atualizar o blog, finalmente 

retornamos a atualizar.

Pedimos desculpa pela demora, mas é que estavamos a espera

atualização do modelo de entidades e relacionamento de banco

de dados para o atual escopo do projeto. Não atualizamos o

blog anteriormente pois isso acarretaria em inconsistencias  

dos documentos.

Nesse endereço estamos postando o modelo referido 

para a base de dados do sistema:

     http://www.students.ic.unicamp.br/~ra060639/bHappyDB.png

Nesse modelo apresentamos as alterações na estrutura de como

seriam relacionados o registro de interesse de um cliente por um

estabelecimento. Ao invés de o dono do estabelecimento ter que 

ficar criando vários eventos, esse agora só atualizará o cardápio

e atrações do estabelecimento. Dessa forma o cliente declarara

somente o dia que tem interesse em ir ao estabelecimento.

terça-feira, 13 de maio de 2008

Revisão das Metas e testes

Os dois foram revisados é já se encontram atualizados no seguinte endereço: http://www.students.ic.unicamp.br/~ra058928/mc750/

Por enquanto é isso.

terça-feira, 6 de maio de 2008

Documentos de Teste

Há muito, muito tempo, em uma galáxia muito, muito distante...

...foi pedido aos alunos que desenvolvessem a documentação referente ao plano de testes a ser realizado nas interfaces. O plano de testes consiste em dois documentos, um contendo as metas a serem atingidas e outro descrevendo como os testes seriam realizados.
Os documentos haviam sido feitos, mas faltava o 'acabamento final': revisão e definição de alguns pontos questináveis entre os próprios membros do grupo. Neste meio tempo, surgiram provas, trabalhos e, claro, feriados prolongados.
E eis que só hoje, em um momento de aparente calmaria, concluiu-se e uploadou-se os devidos documentos.

São os documentos 03 e 04 do diretório:
http://www.students.ic.unicamp.br/~ra058928/mc750/

segunda-feira, 28 de abril de 2008

Alterações no projeto

Após uma série de discurssões em nosso grupo
chegamos a conclusão que registrar diversos eventos
para cada estabelecimento levando a complexidade
do tanto, de projeto, quanto para utilização do usuário.
Por isso, decidimos reformular a estrutura
organizacional para a aplicação.
Chegamos ao concenso, que somente deveríamos
armazenar somente os dados dos estabelecimento e
as promoções para cada estabelecimento teriam um
registro uníco que deverá ser atualizado com devida
frequência.
Dessa forma, o cliente verificaria esse cardapio,
atrações ou promoções antes determinar a escolha
de interesse em ir ao estabelecimento.

Agora, iremos reestruturar a base de dados, e basear
o desenvolvimento da interface nesse direcionamento.

sábado, 12 de abril de 2008

Base de dados terminada...

Segue o texto na integra em meu blog...

terça-feira, 8 de abril de 2008

Documento de visão e glossário

Pessoal,
tardo mas não falho.

Coloquei em minha área aberta do IC os documentos de visão e o glossário feito pelo grupo. (preciso aprender a utilizar o GoogleDocs como gente grande. T_T)

Estes arquivos foram feitos por todos os integrantes do grupo, cada um uma parte. Não lembro exatamente o que cada um fez, por isso peço desculpas por não listar as devidas realizações e os devidos créditos.

Segue o link da pasta de arquivos disponíveis:
http://www.students.ic.unicamp.br/~ra058928/mc750/

sexta-feira, 4 de abril de 2008

Personagem definido

Conforme requisitado pelo professor Hans, a criação do personagem esta terminada. Por gentileza, aceito sugestões. Para ler mais a respeito do Sandro Galtran, clique aqui.

Nome do projeto definido

Postado em meu blog.

segunda-feira, 24 de março de 2008

Algumas idéias e problemas...

Comentei a respeito no meu blog. Por gentileza, dêem suas opniões. Acho que precisamos ser mais objetivos no que realmente vamos desenvolver.

Projeto definido...

Depois de várias idéias, discussões e especulações, finalmente o projeto do grupo foi definido. Um gestor de HappyHour. A priori, a ídeia parece ser um pouco estranha. "Happy Hour?? Android?? Celular??". Concordo. No entanto, nas próximas linhas você perceberá como será possivel consolidar tal casamento que parece ser tão incerto.

Todos sabemos, principalmente os que já trabalham, de que para um bom rendimento tanto escolar como profissional, é necessário, durante a semana a realização de eventos de confraternização entre os colegas de ofício. Seja para discutir, ou apenas se socializar. Geralmente, o problema ocorre na definição do local. Dia após dia, o número de estabelecimentos que oferecem esse tipo de serviço cresce consideravelmente. Outro problema bastante comum é a respeito da presença de certos indivíduos. Muitos deixam de ir para o HappyHour porque o fulano disse que não ia, quando naverdade no último instante ele decidiu ir. Ou quando aquele cicrano gente boa disse que ia e ninguem mais quis ir. Portanto, é neste exato dois pontos que nosso projeto pretende focar, isto é, a ajuda na definição de um local e informar quem realmente vai tomar umas.

Em suma, a ídea é bastante simples. Desenvolver um aplicativo que liste todas os HappyHours que ocorrerão naquele dia ou na semana. Tal listagem pode ser filtrada, isto é, o mais próximo do trabalho, os que disponhe de melhores preços ou os melhores de acordo com um ranking de opnião pública. Além disso, quando o usuário estiver pesquisando por tais recintos, o aplicativo também mostraria quais "amigos" do usuário estão interessados em ir para tal lugar. É importante definir no presente momento que o software ira considerar como "amigos" os indivíduos cadastrados na lista de contatos do usuário. Inclusive, quando o mesmo confirmar interesse em estar presente em tal HappyHour, ele poderá enviar convites por SMS ou Email para todos aqueles contatos que ele escolher e que ainda não disseram se estão interessados em ir ao local.

Portanto, tal ídeia vibializa o desenvolvimento de um gestor de HappyHour para a plataforma Android que rodará em Celulares. Com certeza, marcar HappyHours vai ser uma coisa mais rápida, apenas alguns "apertos" no teclado do celular, e fácil, uma vez que SMS ou EMAIL pouparia o tempo perdido nas ligações necessárias para cada uma das pessoas para a divulgação de sua intenção em ir para um lugar.

Próximas metas
- Definir um nome para o projeto
- Definir as interfaces focando principalmente em facilidade
- Estudar o público alvo e entender mais afundo suas necessidades para o surgimento de mais idéias.