Então



A jornada até aqui foi árdua, começou fácil e foi se tornando difícil a cada sexta-feira. Mas nós conseguimos, algumas coisas não foram do jeito que esperávamos, mas demos tudo o que tínhamos e tudo deu certo.

Estamos satisfeitos com o nosso trabalho e esperamos poder aprimorá-lo no futuro.

A semana foi puxada, quase toda noite virando para terminar a aplicação... Dor de cabeça e estresse são constantes, mas estamos quase lá.

Terminamos toda a implementação das cadeiras obrigatórias, optativas e eletivas. Essa parte está 100% funcional, havia ficado pendente a parte da customização, foi mais difícil do que achávamos mas deu certo ;D

Passei praticamente a tarde toda conversando com a Alexia sobre alterações e medidas na interface.
Redefinimos o tamanho de todos os elementos visuais, pois julgamos que os novos valores são os mais apropriados.


Falando ainda sobre alterações, conversamos sobre algumas coisas que modificamos/modificaremos devido a problemas de implementação (tempo e/ou praticidade da solução).

Possíveis alterações:
- A fonte permanecerá padrão do Xamarin até que se consiga alterar para Roboto;
- O peso da fonte de 'disciplinas completas e restantes' na home foi alterada para bold por motivos de legibilidade;
- Adicionar opção de 'nenhuma' na lista de seleção de disciplinas optativas e eletivas;
- Possibilidade de alterar a atividade complementar de lista com dropdown para pop-up.

A vida de estudante não é fácil e contamos com alguns imprevistos, mas deu tudo certo. Até agora.

Design

Sobre o projeto como um todo, ficou decidido que a Géssica iria criar um documento informando como nós da programação iríamos lidar com alguns 'aspectos' do aplicativo, no caso mensagens e notificações para o usuário a medida que ele interage com o sistema.

O documento que ela preparou foi: Definições de interação.

Ela também ficou responsável por definir/produzir alguns materiais relacionados às atividades complementares.
Temos então o seguinte documento: FAQ Atividades.

Também foi pedido que ela fizesse uma espécie de fluxograma das páginas e indicasse onde o usuário poderia interagir, dessa forma a gente (Lucas e Yuri) não ficaríamos fazendo suposições na hora de criar as telas e programar.

O resultando foi o seguinte:




Depois que eu fiz umas telas já para a implementação, a Alexia percebeu que o espaçamento não tava muito bom. Então ela fez umas especificações para nos nortear.

Programação

"Instancio uma database dentro do próprio aparelho utilizando o SQLite, uma ferramenta criada exatamente para esse tipo de função. Nessa database é criada uma tabela de objetos da classe "Disciplina", que armazena os seguintes dados: número de identificação, nome, semestre (0, no caso de opcional), tipo de disciplina (obrigatória, eletiva e opcional) e um condicional para checar se ela já foi marcada como feita pelo usuário. "


O que eu faço/fiz :

O Protótipo

Para o protótipo definimos o seguinte:

• Fazer com que as disciplinas fossem dispostas nos semestres;
• Possibilitar ao usuário marcar quais disciplinas ele realizou; ** No caso apenas as obrigatórias.
• Informar o número de disciplinas feitas, bem como o número das pendentes.
• Atribuir alguns elementos visuais ao código funcional.

Desde a última documentação de progresso nós nos reunimos para definir mais algumas coisas do aplicativo (telinhas, ícones, disposição dos elementos e detalhes menores em cada página).

Fizemos uma reunião completa dia 29, domingo, onde a reunião foi focada em alguns levantamentos que a Alexia tinha para fazer. Questão de número de páginas, como o usuário iria interagir a partir do menu, onde ele iria clicar e para onde iria.

A reunião foi conduzida pelo hangout, fizemos um breve documento, porém o mais importante foram alguns 'acertamentos' que fizemos entre si.

Sobre o protótipo, fizemos significativos avanços para concluí-lo e apresentá-lo dia 10/06. Eu, Lucas, desenvolvi a tela de 'home' utilizando placeholders e trabalhei com imagens, ícones, espaços, cores e outras propriedades dos elementos para ver como distribuir a informação que queríamos e para ver se o que pensamos era realmente possível.  Apanhei um pouco para o XML, mas deu tudo certo. A imagem a seguir é um pequeno resultado do que estamos fazendo.

Com a parte da programação, o Yuri pensou em algumas outras formas de trabalhar com as disciplinas e como tratar da divisão dos tipos delas. Ele se encontra na parte de testar a interação entre as páginas e dispor o resultado corretamente
A Géssica e Alexia contribuíram adiantando algumas outras telas e como elas funcionarão. Ficou acordado que, para facilitar o lado da programação, elas criariam um documento contendo todas as informações de interações e possíveis eventos em que o usuário participaria. Ex: pop-ups, eventos que podem ocorrer, mensagens de confirmação, telas de erro, etc.

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.