Desde a última entrega, sentimos que adiantamos muita coisa. Até agora, o desenvolvimento da parte visual está indo muito bem e todos os membros estão participativos, algo muito positivo para a finalização do trabalho.


E então, o que fizemos ?

~Pontos Importantes~

Dia 16, segunda passada, reuni-me com a Géssica para resolver algumas pontas soltas e deixar claro algumas decisões de interação e algumas coisinhas de design, além de falar como funcionaria alguns pontos da programação (visão dos programadores). A reunião foi conduzida no hangout, fizemos um "documento" bem básico com alguns pontos chaves da reunião.
Nesse dia a Alexia e o Yuri não puderem comparecer, mas tudo foi repassado para eles via facebook/wpp. Nesse dia debati várias ideias com a Géssica de como poderia funcionar a interação do usuário e como isso afetaria a programação, foi importante porque deu pra esclarecer muita coisa e a Géssica deu muita sugestão para a programação.


Dia 17, terça passada, a Alexia, a pedido do Yuri, encaminhou todos os materiais que ela havia utilizado para os protótipos e alguns outros que seriam necessários para o desenvolvimento da versão beta. Ela também disponibilizou as telas finais de como seria a aplicação.
Tudo pode ser encontrado > aqui <.

Depois disso me reuni algumas vezes, ao longo da semana, com o Yuri para debater sobre algumas estratégias que poderíamos adotar para fazer a versão beta. Estratégias referentes a como lidar com as disciplinas, como dividi-las em tipos diferentes a serem identificados no programa e como tratar a questão da obtenção e disposição da informação de quantas cadeiras foram completadas ou estão pendentes.
A gente fez então esse documento: doc programação

Yuri também comentou todo o código que tinha feito e me repassou, de forma que a gente ficasse na mesma 'página' e não se confundisse na hora de desenvolver.



• Ficou decidido que o Yuri ficaria com a parte da 'programação pesada' das coisas e eu, Lucas, ficaria responsável por organizar os elementos visuais através do XML, pois concordamos que uma pessoa só, ficar responsável por tudo isso, iria ficar sobrecarregada.




O que cada um fez/planejou ? 
Os textos a seguir foram feitos pelos próprios integrantes.

UX Design - Géssica : Foram feitas avaliações nos protótipos desenvolvidos até o momento e encaminhadas melhorias de UX/UI a serem implementadas no desenvolvimento da versão beta da aplicação. Assim que a versão for finalizada, será feito um relatório de avaliação e apontamento de correções para as versões seguintes.

Design de Interface - Alexia: Toda a interface para o desenvolvimento do aplicativo beta foi entregue para os programadores na terça-feira dia 17/05/, contendo as especificações de cores, posicionamento, ícones e tipografia a ser utilizada, bem como imagens extras (logo e imagens do passo-a-passo). Para adiantar a entrega e viabilizar a análise por toda a equipe e, principalmente, pela UX Designer (Géssica), estou terminando os mockups da tela onde o usuário visualiza as disciplinas Obrigatórias, Eletivas e Optativas. Assim que essa parte for concluída, será postado no blog as imagens e a interação utilizando o Invision App.



Liderança/Planejamento/Programador 2 - Lucas: Consegui articular bem o pessoal e deixar todo mundo na mesma 'página' do desenvolvimento, cada um sabe o que tem que ser e o que os outros estão fazendo. A Alexia inclusive não deixa a gente esquecer. Com as reuniões e conversas que tivemos ao longo das semanas, ficou claro o que está faltando no desenvolvimento, principalmente o que falta na programação. Combinei com o Yuri de que ficaria responsável por organizar os elementos visuais através do XML, porém não é tão simples quanto parece.

Organizar as imagens que a Alexia passou de forma que tudo fique agradável é bem demoradinho, pois ficar indo pro XML, ajustar as variáveis, e voltando para a tela do aplicativo, para ver se ficou bom, é bem chato.
A ideia é que eu faça a organização dos elementos da melhor maneira possível, que aí junto com o Yuri a gente junta a parte visual e a programação. Porque se ele fosse programando e ajeitando os elementos ao mesmo tempo, demoraria muito.




Programador Chefe - Yuri: Para o beta do projeto foi planejada a forma de como os dados dos semestres e das disciplanas serão estruturados e como eles serão apresentados nas telas. A implementação deles está em desenvolvimento.




Sobre os Posts no Blog

Nesse ponto, realmente pecamos, apesar de termos feito muitas coisas, acabamos deixando as postagens nos blogs um pouco de lado. Essa postagem é um apanhado de tudo o que fizemos desde a última entrega.

Nos comprometemos em atualizar mais o blog a cada progresso feito, seja ele grande ou pequeno.



Onde Estamos ?

Acredito que a área de 'destaque' aqui é a parte da programação, pois compete a mim e ao Yuri terminarmos o protótipo beta. No momento estamos desenvolvendo o que foi discutido em equipe, se tivesse que chutar uma porcentagem, diria algo em torno de 50%. Até sexta feira que vem, dia 3, acredito que teremos terminado tudo sem maiores problemas.
Esse protótipo é muito importante, pois se conseguirmos fazer o que planejamos, replicar o resultado para a aplicação toda será excelente.

Para deixar claro, nosso protótipo consiste em fazer com que o usuário marque quais disciplinas ele já realizou (no caso será do primeiro semestre) e aí geramos os dados que correspondem ao progresso que ele realizou, dispondo tais informações em outras páginas (home ou páginas específicas da informação escolhida, como apenas cadeiras concluídas, apenas cadeiras pendentes, etc...)

Um ponto importante que não foi citado é o cronograma, tivemos muitos imprevistos (viagens, feriados, etc) e basicamente deixamos ele de lado. Porém estamos desenvolvendo bem, mas acredito que será necessário refazer o cronograma.



E é isso :)

Acreditamos que, com esse post, deixamos claro o que estamos produzindo e, o mais importante, é que todo mundo está participando e cumprindo com o que foi prometido. Ainda mantemos nossa ideia de que o projeto dará certo e conseguiremos terminá-lo no tempo certo.

Acreditamos que nossa equipe está indo bem no desenvolvimento do projeto. Até a presente etapa conseguimos resolver, sem maiores problemas, tudo o que foi imposto pela cadeira e por nós mesmos. Após a etapa de prototipação conseguimos consolidar a maioria das informações que usamos nessa sétima tarefa.

Relembrando a nossa proposta: Aplicação para dispositivo móvel em que o discente poderá acessar informações sobre suas pendências na matriz do curso, além de informações sobre as atividades complementares.

Link para Documento Completo : Clique Aqui.

Tecnologias e Ferramentas
Para a programação e o aspecto técnico em si dispositivo móvel temos:

• Dispositivo Android: versão Mínima 4.4, API 19, “KitKat”. Atendendo a maioria dos dispositivos: estatísticas;
• Tamanho de Tela: android one - dimensões : 4.5 cm 2.2 x 3.9 cm ; ratio 16:9; 320 x 569 dp | 480 x 854 px: referência;
• Framework Xamarin: programando em C# na IDE . Na versão Xamarin.android 6.0.3; juntamento com o Android SDK Tools 25.1.3 e JDK 1.8.0_92. Com o Emulador Genymotion. 
• Desenvolvimento de Telas: Adobe Photoshop CC 2015;
• Teste de Layout e Usabilidade: Invisionapp, que permite a simulação de uma interação do usuário com as telas; 
• Informação da Matriz e Atividades Complementares: Escolhemos por não utilizar banco de dados ou algum outro recurso, acreditamos que implementar tal conteúdo em ‘hard code’ será mais simples, apesar do trabalho manual.

UI Design:
O protótipo I foi o escolhido para continuar no desenvolvimento do aplicativo por atender as necessidades de organização e disposição das informações de forma mais adequada, bem como estar dentro da maioria das 10 heurísticas de usabilidade Nielsen, onde verificamos as atividades e telas mais frequentes no aplicativo. Relembrando a postagem dos protótipos UI: as informações dispostas tiveram mais foco no protótipo I, além da continuidade e transição dentro do sistema Android (Material Design). Mesmo tendo características muito semelhantes, conseguimos desenvolver uma interface com características peculiares, atrativas e instigantes.

1. Visibilidade de Status do Sistema (informar ao usuário o que está acontecendo): Serão aplicadas as caixinhas de diálogo e feedback instantâneo nas próximas telas;
2. Relacionamento entre a interface do sistema e o mundo real (não usar palavras de sistema, que não fazem sentido pro usuário): OK;
3. Liberdade e controle do usuário (permitir desfazer ou refazer a ação no sistema e retornar ao ponto anterior): OK;
4. Consistência (fale a mesma língua o tempo todo): OK;
5. Prevenção de erros: OK;
6. Reconhecimento ao invés de lembrança (evitar acionar a memória do usuário o tempo inteiro): Do protótipo II para o protótipo I - adaptar a interface de forma que o usuário tenha ajuda contextual durante a seleção das disciplinas ao invés de relembrar ações pela memória;
7. Flexibilidade e eficiência de uso (fácil para usuários leigos, mas flexível o bastante para se tornar ágil à usuários avançados): Do protótipo II para o protótipo I - Indicadores de quantidade de disciplinas concluídas na tela de semestre, permitindo visualizar o total em cada semestre de forma rápida;
8. Estética e design minimalista (Evite que os textos e o design fale mais do que o usuário necessita saber.): OK;
9. Ajude os usuários a reconhecer, diagnosticar e sanar erros (mensagens de erro do sistema): ainda será aplicado;
10. Ajuda e documentação (auxiliar o usuário em caso de dúvida): ainda será aplicado;

O desenvolvimento a partir de agora será para aplicar o restante das heurísticas de forma satisfatória e projetar as telas das funcionalidades restantes seguindo o mesmo padrão.

Os elementos gráficos e tudo o que envolve layout serão feitos em photoshop pois é a ferramenta que atende todas as necessidades nessa área. Quanto ao invision, o mesmo possibilita emular as telas em um dispositivo android e simular a interação do usuário, permitindo então que desenvolvamos telas com maior confiança, uma vez que poderemos testá-las de fato.



UX Design:
A equipe elegeu o Android como sistema operacional a ser explorado durante o desenvolvimento da aplicação visando as capacidades de cada integrante. O Android oferece suporte para vários tamanhos de tela e densidades, refletindo as várias configurações de tela que um dispositivo possa ter, assim realizamos testes visando a utilização da aplicação em diversos aparelhos.

Ao fim da execução dos testes em protótipo a equipe chegou a conclusão de limitar as telas de execução da aplicação mobile para a de características mais utilizadas segundo pesquisa disponibilizada via Google através do site referência Android Developers, ou seja telas com tamanho normal (pelo menos 470dp x 320dp) que compreendem 85,7% dos dispositivos com o sistema operacional, e densidade Hpdi (aproximadamente 240dpi) que comporta 41,9% dos aparelhos. Os aparelhos com as configurações definidas foram representados no teste em questão pelo dispositivo Moto G1, com tela de 4,5 polegadas.

Optou-se pelo modo de utilização retrato, possibilitando a utilização da aplicação com uma só mão que é favorecida pelas características escolhidas, e interação utilizando “Tap” ou “Click” para a navegação, visando disponibilidade de tempo para desenvolvimento por parte da equipe e a otimização da experiência do usuário. Assim como priorizou-se a visualização em “lista” em detrimento da visualização em “grade” gerada para a realização dos testes em tablets.

Programação e Aspectos Técnicos:
Utilizaremos o Xamarin para desenvolver a aplicação, pois concluímos que será mais proveitoso, uma vez que sentimos mais facilidade em codificar e o mesmo atende nossas necessidades quanto a implementação das funcionalidades propostas. Um fator decisivo foi que entendemos muito mais facilmente como trabalhar com os elementos Quanto à versão kitkat que foi escolhida, isso ocorreu pois a mesma engloba a grande parte dos dispositivos móveis, segundo dados da própria google. Podemos, assim, alcançar o maior número de pessoas.

Em relação ao tamanho da tela, acreditamos que ao escolher uma tela com dimensões menores e dispor a informação de maneira adequada nela, facilmente poderemos reproduzir o resultado para telas com tamanhos maiores, através de recursos como responsividade e o peso dos elementos no espaço.

Contudo, o Xamarin possui alguns elementos que podem dificultar o desenvolvimento do aplicativo. O mais evidente deles é a criação de arquivos xml, que servem para desenhar o layout das telas, pois é bastante engessada e exige muita experiência por tentativa e erro.

Por outro lado, o desempenho do software é bem mais atrativo que o de outra ferramenta testada pela equipe: o Android Studio. Nesse último a memória do computador é sofre uma demanda grande, tornando-o pesado e lento, principalmente no que se refere ao building do projeto trabalhado, o que não ocorre no Visual Studio.

Também há a questão da linguagem de programação que mais agrada aos programadores da equipe. Geralmente aplicações para Android são feitas em Java, porém consideramos ela um tanto desconfortável, pois exige muita escrita para fazer pouca coisa. Dito isso, optamos por procurar uma ferramenta na qual fosse possível desenvolver em C#, que o Xamarin usa justamente para o seu serviço de desenvolvimento multiplataforma e que também é orientada a objeto como como o Java.

Complexidade e Viabilidade:
No design de interface, a complexidade é média. A dificuldade se restringe apenas na organização das informações, que requer mais atenção e cuidado para não prejudicar o usuário no que diz respeito a localizar e interpretar a mensagem que queremos transmitir. Para contornar tal situação, é necessário que estudemos a melhor maneira de dispor o conteúdo nas telas, a melhor maneira é testando diferentes arranjos, processo de fácil execução e viabilidade, tendo em vista a experiência que nosso designers possuem com as ferramentas escolhidas e o tipo de serviço que já desempenharam; o contraponto seria o tempo, porém acreditamos que temos o necessário para executar tal tarefa de maneira satisfatória.

Referente a experiência do usuário, consideramos a complexidade média, uma vez que dispomos de uma grande quantidade de demanda, em contraponto ao fato que além de desenvolvedores também somos clientes, por isso podemos ter uma melhor visão do que seria o ideal as necessidades apresentadas.

O Android oferece suporte para vários tamanhos de tela e densidades, você pode usar recursos do sistema para otimizar a interface do usuário do aplicativo para cada configuração e garantir que a sua aplicação rode corretamente, mas nem sempre proporciona a melhor experiência de usuário possível. O Android faz com que essas diferenças abstrato para aplicações, para que possa fornecer UI projetado para os tamanhos e densidades generalizadas e deixar o sistema lidar com os ajustes finais conforme necessário. Por isso consideramos a complexidade média, porém pouco viável, já que para garantir uma boa experiência seria necessária a personalização da interface para para configuração de tela, o que não seria possível em tempo hábil. 

Em relação a parte programação do aplicativo a complexidade de implementação é média para alta. Há um quantidade enorme de combinações que o usuário pode fazer enquanto utiliza o aplicativo e elas tem de ser alteradas dinamicamente, o que pode vir a se tornar um desafio. No entanto, para deixá-lo mais simples e viável optou-se que o aplicativo fosse desenvolvido visando apenas o curso de Sistemas e Mídias Digitais, limando a necessidade de um banco de dados online e de criação de um perfil de usuário.

Restrições:
Não enfrentamos nenhuma restrição orçamentária, pois já possuíamos a maioria dos softwares necessários para o projeto e os outros foram obtidos gratuitamente, com a opção de licença grátis. Também não há restrições espaciais, não precisamos de nenhum espaço para desenvolver a aplicação ou de um local físico para distribuí-la.

A maior restrição talvez seja com o tempo que temos para finalizar o projeto, entretanto, até o presente momento, nossa equipe conseguiu, com sucesso, entregar todas as atividades sem dificuldades e até adiantando algo para os processos passos. Acreditamos que entregaremos o que foi proposto.

Sobre a aplicação, é necessário que o usuário possua um dispositivo com sistema Android compatível com a versão KitKat. De forma a distribuí-la temos a opção de disponibilizá-la na PlayStore ou através de algum link para download onde o usuário conecta seu dispositivo ao computador e transfere a aplicação via USB.




Link para Documento Completo : Clique Aqui.

INTRODUÇÃO
Eu já tinha alguma experiência em desenvolvimento para Android utilizando o Android Studio e sabia alguma de suas limitações, como o grande uso de memória. Além disso, eu também estava interessado em desenvolver para iOS, o que nunca tinha feito, e acabou pesando para a escolha do Xamarin como plataforma de desenvolvimento.

No entanto, após algumas tentativas de projetos e pesquisas, percebi junto a equipe que desenvolver para iOS seria bastante complicado pela falta de um aparelho para fazer um debug mais preciso e pelo o tempo que seria gasto pesquisando como trabalhar com as especificações dele.

Decidido isso, passei a buscar apenas por soluções que utilizassem o xamarin.android, não o xamarin.forms (que é o utilizado para fazer aplicações multiplataformas).

Os testes foram feitos nas resoluções do Samsung Galaxy S4 e do Google Nexus 5 e nas APIs de nível 19 e 22 para testar como aparelhos relativamente parecidos, mas com Android de tempos diferentes se comportariam.

PRIMEIRO PROTÓTIPO
De início eu segui alguns tutorias bem simples de mudança de tela e criação de layouts para me adequar melhor à ferramenta. Após isso comecei a estudar qual seria a melhor forma para escrever o nosso conteúdo no aplicativo. Na introdução do aplicativo, por exemplo, procurei ver como adaptar a nossa possível UI para obter um equilíbrio na parte de desenvolvimento de lógica e de design. A parte mais interessante foi fazer os passos da apresentação, pois procurei usar só uma tela e mudar os elementos dela dinamicamente. Para o perfil que vem logo após usei apenas uma image de place holder, porque pretendia deixa a criação de uma interface mais elaborada para um protótipo futuro, quando já estivesse totalmente a par das funcionalidades do Xamarin.
SEGUNDO PROTÓTIPO
O protótipo seguinte já se mostrou um desafio maior. A princípio ele seria apenas um estudo de como seria implementada função de busca por disciplinas, mas também quis testar logo o desenvolvimento da UI nem que fosse de uma forma mais bruta. Então utilizei as cores e o layout de um protótipo de mockups diferente do meu primeiro protótipo para testar como seria a criação de um arquivo de xml diferente. A primeira tela, com os semestres lado a lado foi tranquila. Passei a utilizar a propriedade de pesos dos elementos no xml para fazer uma simetria bem apresentável.


O passo seguinte foi bem trabalhoso, visto que ainda não tina trabalhado com edição de ListView, mas creio que tenha sido bem útil para pela aprendizagem que será aplicada diretamente no aplicativo.

Quando aplicava um ListView padrão o desenho da página quebrava com frequência, além da fonte, que deveria ser preta, se torna branca. Depois de muita pesquisa achei essa série de vídeos que explica que explica bem essa funcionalidade e, da qual, eu pude me inspirar para fazer minha própria lógica.

Deixei os botões da lista de disciplina sem animação original, o que ainda estudarei como desenvolver. Contudo, se o usuário clicar em uma disciplina que deve ser preenchida (eletiva ou optativa), ele é redirecionado para a tela de busca.

Logo após isso veio a funcionalidade de autocomplete (o objetivo original desse protótipo). O problema é que a barra automática onde os resultados da busca são mostrados apresentava fonte e fundos brancos, o que me fez gastar mais tempo pesquisando, só que dessa vez não obtive tanto sucesso. Foram encontrados algumas soluções, mas todas em java e a conversão delas para o C# foram bem problemáticas.

Como medida provisória troquei apenas o tema do aplicativo para a atividade em questão. Posto isso, alguns estudos serão feitos para fazer essa funcionalidade de uma maneira mais elegante, pois na forma atual algumas APIs não puderam contar com o tema mais atual.

No primeiro exemplo é o do Samsung com API 19 e logo após o do Google Nexus com API 22:

Apesar de termos idealizado que a aplicação android seria desenvolvida utilizando o framework Xamarin, não havíamos feito essa escolha baseada em testes práticos, apenas no "vamos fazer, porque sim".
Portanto, a motivação por trás desses dois protótipos era:

• Testar ambas as ferramentas, para saber o que elas possibilitariam.
• Verificar o nível da facilidade de desenvolvimento, no que diz respeito a linguagem, em cada uma, para saber em qual poderíamos desenvolver mais rápido. 
• Testar o que ambas poderiam oferecer no que diz respeito a parte gráfica, isto é, se é fácil implementar os elementos visuais necessários a aplicação.
• Verificar qual ferramenta é mais adequada para desenvolver nos equipamentos que nós temos, isso é, se um programa é incompatível ou não funciona corretamente.

Neste momento foram desenvolvidos protótipos buscando investigar 2 subproblemas que surgiram no decorrer de nosso desenvolvimento. Um problema funcional, referente a responsividade do aplicativo, uma vez que a equipe havia definido como requisitos mínimos a versão 4.4 (KitKat) do sistema operacional Android, foi levantada a questão da adaptação da aplicação para dispositivos de diferentes tamanhos de tela, tais como tablets.

O segundo protótipo foi desenvolvido para testar a melhor aplicação visual e de interação do usuário com a plataforma, levantando-se a questão da utilização das interações via “Slide”, em que o usuário arrasta seu dedo na tela para navegar entre os semestres, ou “Tap” em que o usuário clica na tela para executar as ações.

Para a criação dos protótipos acima citados, foram desenvolvidas telas ainda experimentais utilizando o Software Adobe Photoshop, que depois foram aplicadas a plataforma online Invision para o desenvolvimento das interações. Vale ressaltar que a plataforma Invision possui limitações técnicas tais como: exibição da url durante a apresentação via mobile e atrasos na execução de interações. Apesar disso a equipe concluiu que a plataforma era a mais adequada para as propostas de protótipo a serem executadas.


Durante a execução foram utilizados os aparelhos Motorola Moto G1 e Samsung Tab S, com 4.5" e 10.5 polegadas de tela respectivamente, para os testes de interação em “Slide” e em diferentes telas com interação em “Tap”. Após a utilização da plataforma Invision, foi gerado link para exibição online, executado nos dispositivos já citados. Para a execução do teste no tablet foram desenvolvidas telas específicas que: simulariam a interação em dispositivos maiores e acrescentam uma opção de interação por “Tap” ao protótipo anterior.

Primeiro protótipo: Esse protótipo foi produzido com o intuito de testar a possibilidade de interação via slide na navegação entre semestres, em contraponto a navegação em "Tap" ou "click" apresentada no segundo protótipo. Levantamos essa questão buscando soluções que tornassem mais rápida a utilização da aplicação. As telas foram modificadas exclusivamente para utilização nos testes, buscando uma melhor visualização do que seria o efeito "Slide".



Segundo protótipo: Esse protótipo foi produzido com foco na possibilidade de adaptação da aplicação a dispositivos com diversas proporções de tela suportados pela plataforma Android e na possibilidade de interação via "Tap" por parte do usuário, representada pela disposição em "grid". As telas foram modificadas exclusivamente para se adaptarem as proporções do dispositivo durante o teste, ou seja Samsung Tab S com 10.5 polegadas, escolhido para demonstrar a diversidade extrema de telas a serem exploradas pela equipe de desenvolvimento.


Ao fim da execução dos testes em protótipo a equipe chegou a conclusão de limitar as telas de execução da aplicação mobile para a de características mais utilizadas segundo informações disponíveis no site Android Developers, ou seja telas com tamanho normal ( pelo menos 470dp x 320dp), com densidade Hpdi ( aproximadamente 240dpi), modo de utilização retrato e interação utilizando “Tap” para a navegação, visando disponibilidade de tempo para desenvolvimento por parte da equipe e a otimização da experiência do usuário uma vez que a variedade de telas disponíveis para o sistema operacional poderia prejudicar a adaptação da aplicação.

Links para protótipos:

• Prótotipo interação Moto G1;
• Protótipo responsividade e interação tablet;

Links para vídeos:

• Protótipo de interação;
• Protótipo de interação e responsividade;

Nesta fase do desenvolvimento do aplicativo, foram criadas duas propostas de interface tendo como base a persona, a interface do site do curso de Sistemas e Mídias Digitais e como objetivo a análise das necessidade da organização e disposição das informações, bem como o visual das telas, buscando melhorar a experiência do usuário. Foram utilizadas as 10 heurísticas de usabilidade Nielsen como diretrizes, verificando as atividades mais frequentes no aplicativo e atividades que poderiam apresentar problemas para a compreensão do usuário. Os protótipos para interface foram criados no Software Adobe Photoshop, aplicadas a plataforma online Invision para avaliação da navegação e da interface do usuário, além de gravadas com o software Adobe Captivate.

Ambos os protótipos foram desenvolvidos para telas com tamanho normal (mínimo de 470dp x 320dp) e densidade Hpdi (240dpi). Seguimos também o guia de estilo do Materia Design, buscando manter alguns princípios do sistema dentro do aplicativo, permitindo que o usuário identifique áreas de interação, padrões visuais e o que é necessário fazer para concluir uma ação. A partir dos primeiros parâmetros selecionados de tela, as interfaces foram criadas com as seguintes métricas: grid de 4 colunas com espaçamento de 16dp em visualização vertical e área de toque entre 40-51dp (7-9mm).

Primeiro protótipo:

• Cores: Foram selecionadas duas cores encontradas no site do SMD e modificadas para que contrastassem de forma harmônica na interface, permitindo distinguir os elementos, seja de áreas clicáveis e/ou quando acontece alguma interação.
• Ícones e imagens: Optamos pela utilização dos ícones de sistema disponibilizados pela Google para garantir que as convenções dos usuários de Android se mantivessem. Já as imagens utilizadas no passo a passo e premiação possuem características diferentes de todo o sistema, a fim de ressaltar e auxiliar o usuário na identificação do significado da mensagem passada. Imagens simples e de fácil legibilidade, com linhas grossas e fundo coloridas para destaque.
• Fonte: Mantivemos a fonte padrão Roboto, utilizada nos sistemas Android, pois, da mesma forma que os ícones, evitamos o choque na identificação e leitura dos usuários durante a navegação no sistema para o aplicativo.

Segundo protótipo:


Análise e constatações:

• heurística: Visibilidade de status do sistema, Ajuda aos usuários a reconhecer, diagnosticar e sanar erros, Ajuda e documentação e Prevenção de erros: ainda não aplicado nos protótipos;
• heurística: Liberdade e controle do usuário: a qualquer momento o aluno poderá retornar aos semestres respectivos de desmarcar alguma opção selecionada por engano;
• A criação dos protótipos permitiu observar onde deve-se manter o foco do usuário e a hierarquia das informações em prol de uma interface agradável aos olhos, mesmo contendo bastante informações.
• O protótipo 1 servirá como base da interface a ser desenvolvida, pois com ela as informações dispostas tiveram mais foco, além da continuidade e transição dentro do sistema Android, porém, ainda permitindo acrescentar características únicas (heurística: Consistência e Estética e design minimalista).
• Componentes do protótipo 2 que passarão a incorporar o protótipo 1:
• Diálogo mais humanizado, claro e conciso. Subtítulos engraçadinhos para criar uma relação entre aplicativo e usuário (heurística: Correspondência entre o sistema e o mundo real);
• Indicadores de quantidade de disciplinas concluídas na tela de semestre, permitindo visualizar o total em cada semestre de forma rápida (heurística: Flexibilidade e eficiência de uso);
• Home com informações curtas e rápidas. Possibilidade de alterar as mesmas para gráficos (heurística: Flexibilidade e eficiência de uso);
• Imagem do usuário para personalizar o sistema;
• Componentes do protótipo 1 que serão modificados:
• Tela de semestres sofrerá alterações para receber de forma adequada as badges a medida que o usuário completar as disciplinas de cada semestre;
• Notificações e mensagens de incentivo (heurística: Visibilidade de status do sistema).
• heurística: Reconhecimento ao invés de lembrança: É preciso melhorar/adaptar a interface de forma que o usuário tenha ajuda contextual durante a seleção das disciplinas ao invés de relembrar ações pela memória;

Para começarmos a pensar nos protótipos tivemos que pensar no seguinte item: Por que Prototipar ?

Bom, já imaginamos nosso projeto de várias maneiras, nos reunimos, modelamos e viajamos na maionese. Paramos então de pensar no que poderíamos fazer para nos concentrar no "Essas coisas são realmente possíveis ?".

Sob perspectiva de programação, temos que avaliar os aspectos técnicos das ferramentas e linguagens que desenvolveremos, de forma a saber se as ideias que foram propostas poderão ser implementadas de forma adequada e qual a melhor ferramenta para isso.

Sob a perspectiva do design da interface, temos que atentar para:
- O arranjo e características dos elementos na interface, de modo a possibilitar que o usuário identifique, rapidamente, os elementos e os compreenda sem maiores dificuldades.

Já em relação ao design de interação:
- Encontra a melhor maneira de possibilitar ao usuário de interagir e navegar pela aplicação, de forma que ele possa' alcançar seus objetivos' da forma mais simples e prática possível.

Com tudo isso em mente, a equipe The LYGA estabeleceu os seguintes protótipos a serem desenvolvidos:

• Dois protótipos de mock ups das telas da aplicação, onde será testado possíveis variações de layout (cores, botões, organização dos elementos, sequência de páginas, disposição da informação);
• Dois protótipos que tratam sobre o desenvolvimento de aplicações Android na ferramenta Android Studio e no framework Xamarin, verificando o que cada um tem (ou não) a oferecer; 
• Dois protótipos que abordam versões diferentes de como poderá ser a interação do usuário no aplicativo;
• Dois protótipos que testam a viabilidade técnica da implementação de algumas funcionalidades, de forma a saber o nível de dificuldade de execução e se, de fato, será possível implementar no limite de tempo da disciplina.

    Os protótipos poderão ser acessados em seus respectivos posts.

• Protótipo UI;
• Protótipo UX;
• Protótipo Xamarin vs Android Studio;
• Protótipo Funcionalidades;