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;

Introdução
Os alunos, de Sistemas e Mídias Digitais, SMD, apresentam muitas dúvidas sobre os requisitos e pendências a serem quitadas para poder se graduarem. Não raramente, aos se aproximarem do prazo estipulado para se formarem, os alunos começam a ficar ansiosos e aflitos quando o assunto é lidar com as disciplinas restantes e as atividades complementares. Nessa última, os alunos não compreendem facilmente as regras que são impostas e os diferentes tipos de atividades envolvidas.

Em adição a tal situação, os alunos carecem de ferramentas, que sejam objetivas, atrativas e satisfatórias, de acompanhamento da situação de sua graduação.

Objetivo geral
Desenvolver uma aplicação que é, inicialmente, voltada para os alunos de SMD, onde aborda a matriz curricular do curso e as atividades complementares, de forma que o aluno poderá se situar da melhor maneira possível quanto as suas pendências.

Objetivos específicos

• Facilitar a visualização das cadeiras pendentes;
• Elucidar possíveis dúvidas quanto à dinâmica e funcionamento das atividades complementares;
• Auxiliar no acompanhamento e gerenciamento das disciplinas.

Justificativa
Apesar das dúvidas dos alunos serem recorrentes, há uma carência de ferramentas específicas que auxiliem os discentes no acompanhamento das pendências. A ferramenta existente no SIGAA, que pode ser encontrada em ‘Ensino > Consultar Pendências de Conclusão’, não é visualmente agradável e nem permite um maior controle por parte do usuário. Além disso, tal funcionalidade do SIGAA não apresenta maiores informações sobre as disciplinas, como por exemplo o semestre da mesma ou sua descrição.

Quanto as Atividades Complementares, os alunos dispõem apenas de um documento que é obtido, mais comumente, através da lista de emails. O documento explica todo o funcionamento das atividades complementares, porém os alunos o encaram como algo complicado de se entender e, até mesmo, não se sentem estimulados a compreendê-lo melhor. O que na hora de prestar contas das atividades se torna um problema, pois os discentes, as vezes, não sabem onde encaixar as atividades e nem sabem o que vai valer na contagem das horas.

Evidencia-se, portanto, a necessidade do desenvolvimento de uma aplicação que dê suporte aos alunos, que ao ser desenvolvida especificamente para o acompanhamento das pendências e dúvidas relacionadas as atividades complementares deverá satisfazê-los de maneira adequada.

A aplicação proposta consolidará as principais funcionalidades de interesse dos discentes, mostrando-se de grande importância para as suas necessidades de organização. Reforçando os aspectos da solução, propomos o uso de uma linguagem e visual menos formais, mas ainda agradáveis, que aproxime os discentes e o aplicativo, fazendo com que eles se identifiquem com o produto e se sintam motivados e confortáveis  ao utilizá-lo.

Para ajudar nas escolhas do visual e linguagem, utilizamos o Relatório de Evasão referente ao semestre de 2015.2 do curso de SMD, que foi feito pelo professor Emanuel Coutinho, para estabelecermos as principais características (idade, gênero, qual área de interesse no curso, e se já tinham conhecimento, e o que achavam, do projeto pedagógico do curso) do nosso público alvo.

• Faixa etária geral entre 16-30 anos. Sendo o maior número de indivíduos concentrados na faixa de 21-25 anos;
• Presença masculina (66.3%) maior que a feminina (28.8%). Não declarados constituem 4.9%;
• Maiores áreas de interesse sendo Design e Jogos;
• 76.7% se informou sobre o projeto pedagógico do curso.

O Produto
Trata-se de um aplicativo mobile para o Android (menor versão requisitada: KitKat), utilizando o framework Xamarin, que terá como funcionalidades principais:

• Selecionar as cadeiras que já foram cursadas. Sendo elas divididas por semestre, seguindo o que é sugerido na grade disponibilizada no site do SMD;
• Visualizar as cadeiras concluídas;
• Visualizar as cadeiras pendentes;
• Seção contendo as explicações sobre as atividades complementares.

Tais funcionalidades seriam a base do aplicativo, onde apenas com elas, o aluno poderia se situar quanto as suas pendências e sanar suas dúvidas. Isto é, com a aplicação, o usuário poderá facilmente acessar as cadeiras que não foram realizadas, juntamente com a informação sobre qual semestre ela pertence; poderá ver, facilmente, seu progresso em relação ao número de cadeiras feitas ‘vs’ o total necessário; poderá acessar informações sobre o funcionamento das atividades complementares e a importância das mesmas para a sua formação. Tudo isso projetado de forma que o discente possa acessar e visualizar a informação de maneira rápida e satisfatória.

É importante salientar que, em um primeiro contato com o aplicativo, o usuário será introduzido no mesmo através de uma espécie de tutórial-guia.

Se, durante o andamento do projeto, a equipe The LYGA constatar que após a implementação, de maneira satisfatória, das funcionalidades, descritas anteriormente, sobrará um tempo útil, há a possibilidade de se adicionar mais funcionalidades ao aplicativo. Sendo:

• Sugestão de cadeiras relacionadas, a partir das cadeiras já cursadas;
• Exibição e sugestão de trilhas específicas de cada área que o curso possa contemplar. Como por exemplo a trilha de jogos;
• Possibilidade do discente informar quantas horas de atividades complementares, de cada subtipo, foram concluídas. De forma a se obter o total pendente relativo a cada área. Exemplo: O aluno fez 20 horas do campo de ‘Vivência de Gestão’, fica faltando então 28 horas, o que totaliza 48 horas requeridas para esse campo;
• Visualização do aspecto geral do progresso/pendência através de gráficos;
• Adaptar o aplicativo para grades de outros cursos. 

Funcionalidades Principais
Como descrito anteriormente, o aplicativo se baseará em algumas funcionalidades que formarão sua ‘essência’, por assim dizer.

• Informar Disciplinas Realizadas: as cadeiras estarão divididas em semestres e o usuário acessará cada semestre para informar quais já foram realizadas. Cabe então ao aluno modificar e salvar as alterações a medida que for progredindo no curso;
• Visualizar Pendências: nessa parte estarão dispostas as cadeiras pendentes, elas estarão divididas por semestre e terão a diferenciação de tipo, se são obrigatórias, optativas, eletivas ou livres;
• Visualizar Cadeiras Concluídas: funcionará de maneira similar às cadeiras pendentes;
• Atividades Complementares: essa funcionalidade agrupará todas as informações que explicarão o funcionamento das atividades complementares e as regras para se completar a quantidade que é solicitada. O objetivo disso é apresentar de maneira descomplicada e descontraída como as atividades se articulam e são cobradas.

Diagramas e Esquemas
Em um primeiro momento, começou-se a gerar ideias de como poderia ser o aplicativo e o que ele contemplaria, entretanto se fez necessário o desenvolvimento de uma visão mais crítica e técnica da aplicação.

Pensou-se então no que o usuário teria como funcionalidade:
Partiu-se então para o que a aplicação englobaria:

Como o usuário em um primeiro contato será guiado por um tutorial, fez-se então um diagrama de atividade para poder ser definido como seria essa interação: *Apenas uma versão de como poderá ser implementado.

Fluxograma de como seria o primeiro contato do usuário:

Fluxograma de como seria a utilização de um usuário recorrente:

Versão inicial do diagrama de classe


Mockups
Com algumas definições em mente, partiu-se para uma prototipação de como seria o aspecto visual do aplicativo.

Tela do primeiro contato, onde o usuário seguiria pelo tutorial:

Tela para informar dados do perfil e Tela de seleção do semestre  para informar as cadeiras realizadas:

Tela para informar quais disciplinas realizadas no sexto semestre:

Telas alternativas:

Cronograma