- 7.7.16 - 7:53:00 PM
- 0 Comments
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 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.
Aplicação
Makinf Of
Mais telas
- 30.6.16 - 4:06:00 PM
- 0 Comments
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
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
Depois de muita dor de cabeça conseguimos chegar nisso:
Aí depois começamos a brincar:
Então deixamos assim:
Passei então as telas que finalizei, com a aprovação da Alexia, e o Yuri implementou junto com o código.
Nessa parte, estamos mais corrigindo detalhes técnicos do que criando algo visual. Estamos implementando o menu lateral, variados botões que trocam de tela, ordenação das disciplinas em ordem alfabética, customização do listview das atividades complementares.
Terminaremos toda a parte técnica e visual até domingo, com exceção das mensagens de feedback para o usuário em algumas telas (que foi algo que decidimos deixar por último).
Sobre os vídeos, já fizemos um apanhado do que usaremos para fazer as gravações.
Terça, dia 28, finalizaremos os vídeos de apresentação da aplicação e do making of.
- 23.6.16 - 8:09:00 PM
- 0 Comments
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.
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.
Abaixo teremos os prints da tela do Xamarin com a tela da home já com a última implementação, muito provavelmente a versão final (com exceção da fonte).
Destacamos o ponto de que os elementos foram posicionados corretamente, eles se ajustam de acordo com o tamanho do dispositivo e permanecem nos locais a eles destinados.
Um ponto que pretendemos trabalhar é o resize de tais elementos, porém é algo que deixaremos por ultimo pois julgamos que essa característica em específica não é urgente.
Quanto a parte da programação, eu e o Yuri estamos terminando a programação da seleção das disciplinas. Apesar de as vezes surgirem uns bugs, estamos conseguindo corrigi-los.
Pop-up aparece com a lista de disciplinas eletivas disponíveis para o semestre.
O usuário tem que marcar quais cadeiras ele irá fazer, porém as opções de cadeiras eletivas e optativas não devem se repetir caso elas já tenham sido marcadas.
Nossa estimativa é de que a parte, de programação, de selecionar as cadeiras esteja pronta até o domingo. Ficando pendente a parte de estilização dos elementos (campo de viewlist e os pop-ups). Entretanto, já adiantamos algumas pesquisas e juntamos material de referência (tutoriais e documentação do Xamarin) para realizar as alterações.
Como defini as dimensões da tela com a Alexia, o processo de criar as outras é super simples, é mais trabalho 'braçal' de copiar e colar alguns elementos e alterar posições.
Enquanto isso, a Géssica me dá apoio na criação das telas, tirando algumas dúvidas e dando dicas.
A parte em que ela terá mais trabalho será nessa semana que se iniciará, pois pretendemos testar a interação com o aplicativo e procurar maneiras de melhorá-lo.
Sobre os vídeos, já começamos a filmar e juntar as fotos para o making off, pretendemos fazer uma espécie de roteiro para decidir como fazer o vídeo de apresentação do produto.
TLDR: Estamos indo bem. até agora Mantemos a ideia de que conseguiremos entregar o que planejamos sem maiores dificuldades, um ajuste aqui e outro ali acontecerão, mas conseguiremos. Todo mundo fica se cobrando, o que é bom, pois ninguém tem tempo pra procrastinar.
- 16.6.16 - 1:56:00 PM
- 0 Comments
A vida de estudante não é fácil e contamos com alguns imprevistos, mas deu tudo certo. Até agora.
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.
"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 :
Para o protótipo definimos o seguinte:
Design
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
O maior desafio aqui foi fazer com que as informações da aplicação fossem salvas... Mas com um tutorial de um super indiano, o Yuri conseguiu com que fosse possível.
Obrigado Indiano.
O que o Yuri faz :
O que eu faço/fiz :
Debati com o Yuri a melhor forma de salvarmos os elementos na aplicação e como lidar com isso através das funções.
De acordo com o que a Alexia passou, eu comecei a ajustar os elementos com os espaçamentos e tamanhos que ela sugeriu. Alguns problemas surgiram, acreditamos que seja devido a maneiro que o Xamarin lida com as unidades de medida, mas estamos solucionando isso na 'mão' e está dando certo.
Com as telas feitas, eu passo o XML pro Yuri e ele testa ela com a parte da programação.
wow !
much coding !
O Protótipo
- 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.
Pudemos assim testar na prática se era possível fazer o que planejamos. Salvar o 'input' do usuário deu certo, se ele marcar que fez a disciplina, sair e retornar ao aplicativo, estará constando que ele já a fez.
Com isso funcionando, precisamos apenas replicar o trabalho, mas tendo o cuidado de adaptar para as cadeiras optativas e eletivas.
Nosso foco foi esse pois todo o trabalho é fundamento nisso. Ao completarmos isso, o restante do trabalho é replicar o resultado e ajustar os elementos visuais, tarefa que não é complicada, apenas é demorada.cornojob.
Nosso foco foi esse pois todo o trabalho é fundamento nisso. Ao completarmos isso, o restante do trabalho é replicar o resultado e ajustar os elementos visuais, tarefa que não é complicada, apenas é demorada.
-> Apresentaremos o protótipo em sala.
- 9.6.16 - 4:32:00 PM
- 0 Comments
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.
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
- 2.6.16 - 2:33:00 PM
- 0 Comments
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.
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.
Hard Work
• 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.
Mais trabalho
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.
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.
Tirano
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.
- 27.5.16 - 9:08:00 AM
- 0 Comments
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:
Justificativas
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.
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.
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.
Justificativas
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.
- 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;
- 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;
- Liberdade e controle do usuário (permitir desfazer ou refazer a ação no sistema e retornar ao ponto anterior): OK;
- Consistência (fale a mesma língua o tempo todo): OK;
- Prevenção de erros: OK;
- 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;
- 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;
- Estética e design minimalista (Evite que os textos e o design fale mais do que o usuário necessita saber.): OK;
- Ajude os usuários a reconhecer, diagnosticar e sanar erros (mensagens de erro do sistema): ainda será aplicado;
- Ajuda e documentação (auxiliar o usuário em caso de dúvida): ainda será aplicado;
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.
- 12.5.16 - 4:44:00 PM
- 0 Comments
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:
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.
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:
- 6.5.16 - 5:22:00 AM
- 0 Comments
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:
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.
Xamarin
Para realizar o teste do Xamarin, foi necessário instalar o Visual Studio 2015 e atualizá-lo para a versão mais recente. Tive que me cadastras no site do Xamarin para efetuar o download do instalador integrado com o Visual Studio, ao todo foram cerca de 26 gb apenas do Xamarin. O SDK também foi instalado e atualizado para a ultima versão.
Android SDK Tools: 25.1.3
Xamarin.android: 6.0.3
JDK: 1.8.0_92
Para o Emulador, eu utilizei o Genymotion, onde ele apresenta várias opções de dispositivos. Como o protótipo foi para testar as ferramentas, selecionei, sem maiores motivos, o Moto X API 19 720x1280.
Parte 1: Tela Simples
- Iniciei com um tutorial para o primeiro aplicativo, disponibilizado no site do Xamarin (aqui). O tutorial aborda a criação de um projeto do zero, que possui botões, caixas de texto, eventos, permissões do android e alguns outros aspectos técnicos.
- Logo no início é recomendado que instalemos um emulador para o android, entretanto o Yuri me recomendou o GenyMotion, pois um colega de trabalho já havia recomendado. O emulador foi simples de se instalar, foi só executar o instalador e pronto. Voltei para o tutorial.
- A aplicação consiste em 'desvendar' a parte alfabética de um número, liberando então o botão de realizar a chamada.
- Ao final do tutorial eu já havia criado uma aplicação simples, com dois botões e um local para entrada de texto.
- A partir do tutorial eu aprendi a:
- Iniciar uma aplicação com recursos básicos
- Trocar ícone do aplicativo,
- Modificar nome da página onde o usuário se encontra
- Inserir caixas de texto, botões e a possibilidade de alocar outros elementos visuais
- Lidar com as permissões do android e seu 'manifest'
- Modificar os elementos através de suas propriedades e ID no XML e via código
Parte 2: Duas telas
- O tutorial prosseguia para a criação de um novo botão e uma nova tela. Onde esse botão seria ativado após a primeira chamada realizada e nos levaria para o histórico de chamadas.
- Mas antes de começar o tutorial, eu comecei a querer brincar com os elementos da aplicação. Tentei modificá-los, mas percebi que eles não se alteravam. Tirando uma dúvida com o Yuri, bastou modificar no XML do layout a tag geral para 'RelativeLayout', onde antes era 'LinearLayout'. Brinquei então com os tamanhos dos botões e suas posições, simplesmente arrastando eles na tela ou modificando o valor nas suas variáveis.
- Voltando ao tutorial, continuei no mesmo sem maiores dificuldades, criando uma tela 'Activity' nova e fazendo a correlação com o botão que faria essa mudança. Entretanto, no último passo, as coisas não encaixavam e eu não conseguia entender o porque. Tive então que ir buscar o código no github e verificar o que estava errado. Por algum motivo, o que estava no tutorial não correspondia ao que deveria compilar.
- Conclui então o tutorial e o principal que aprendi foi:
- Lidar com mais de uma 'Activity'
- Definir qual 'Activity' seria a inicial, através da definição "MainLauncher = true". O interessante aqui foi que coloquei para iniciar pelo histórico de ligações e o aplicativo parou de responder.
- Associar um novo layout à 'Activity'
Parte 3: Modificando algumas coisas
- Com os tutoriais finalizados, criei uma Activity nova.
- Criei um novo layout e o associei a nova Activity.
- Modifiquei o layout e inseri uma imagem na tela. Utilizei esse link como base.
- Adicionei um botão e fiz com que ao ser clicado ele fosse para o aplicativo em si.
Conclusão: Achei o Xamarin bastante fácil de se trabalhar, apesar de nunca ter desenvolvido nada em C# para android, achei a interface intuitiva e não apresentei maiores dúvidas sobre onde encontrar os componentes. Ao se criar o projeto, logo de cara podemos visualizar a parte do design com os diversos itens que podemos acrescentar na tela a esquerda.
Facilmente se pode alterar o tipo de dispositivo que queremos trabalhar no layout.
Um ponto forte é que a sessão de propriedades do projeto (onde há o 'manifest') é bem organizada e fácil de se mexer, pois a interface é simples e de fácil identificação e manipulação dos itens. Quando colocamos um item na parte do design, facilmente podemos acessar suas propriedades sem termos que ir ao xml.
Um ponto negativo é que a parte para o design das telas/activity peca quanto à organização dos elementos na tela quando falamos sobre o GRID, achei um pouco limitado o quão bem podemos situar um elemento apenas arrastando-o. Tive que recorrer muitas vezes ao XML e modificar lá os números de margem e espaçamentos gerais.
Um grande ponto positivo é que eu achei o desenvolvimento mais 'leve', o computador não sofreu pra compilar e nem pra emular a aplicação no genymotion. Bastando apenas que eu abrisse o emulador no genymotion e então executasse a aplicação, que ela iria direto para lá.
Android Studio
Android Studio versão: 2.1
Android SDK Tools: 25.1.3
Para iniciar o protótipo tive que atualizar o android studio e todos os seus componentes, durou cerca de 3 horas.
- Iniciei o tutorial disponibilizado no site deles.
- O tutorial começava a criação de um projeto do zero. Desde selecionando a versão até o nome e local dos arquivos.
- Essa parte foi bem introdutória, mais teórica mesmo.
- Já na segunda, tratava sobre a emulação da aplicação. Tive um problema logo aqui pois dizia que uma configuração estava desabilitada na bios do meu sistema (vt-x is disabled in the bios), depois de uns 40 minutos consegui resolver.
- Achando que já ia iniciar, tive problemas com o tipo de emulador, pois o 'AS' dizia que o simulador que eu havia instalado não estava instalado (hmmmmmmmmmmmmm). Tive então que instalar outro emulador: Nexus S API 19, 480 x 800 hdpi, Android 4.4. Um problema que identifiquei aqui é que haviam menos opções quando comparado ao Genymotion.
- Mudei então o layout do projeto para o do Nexus S.
- Consegui então emular a aplicação, super básica, logo de cara o computador quase vira um helicóptero processando as coisas. Quando olho, está consumindo quase a memória toda e usando 100% de CPU.
- Iniciei a terceira parte do tutorial. Que é referente a adicionar elementos no layout da aplicação.
- Adicionei um campo de texto e um botão, renomiei o nome que aparece neles no arquivo de strings.
- Simulei a aplicação. É possivel inserir texto no espaço que foi criado, mas apenas usando o mouse para clicar no teclado do simulador.
- Iniciei o tutorial que trata do evento de click do botão.
- Criando a segunda 'Activity' tive muitos problemas, a interface é confusa e no tutorial mandam eu editar um arquivo que simplesmente não existe.
- Retrocedi até o começo do tutorial do evento do botão e recomecei, mas dessa vez ao criar a Activity, selecionei a opção 'Basic' ao invés da 'Blank'/'Empty'.
- Consegui finalizar o tutorial, porém a parte de criar uma nova activity foi muito confusa. Integrar a informação de uma página para outra, apesar de parecer simples, na execução não foi tanto.
- O ícone de mensagem que havia na tela estava me dando nos nervos, encontrei esse link que ensinava a tirá-lo.
- Resolvi mudar então o ícone do App. Cliquei com o botão direito sobre o projeto > new > image asset > nomei e selecionei o arquivo que eu queria.
- Fui então no AndroidManifest.xml, e alterei o 'android:icon' para a imagem que eu queria.
- Criei uma 'tela inicial', onde há um texto, imagem e um botão que deve ser clicado para ir para as telas que fiz no tutorial.
- Criei uma activity chamada 'intro', no seu xml de content adicionei o texto e sua posição, tudo isso na parte apenas do design (arrastando os componentes).
- Adicionei uma nova imagem como asset, adicionei um ImageView e ajeitei o src para a nova imagem nos assets.
- Adicionei o botão e mudei seu texto.
- Mudei no manifest para a pagina inicial ser a intro, link de base.
- Fiz então o botão passar para a próxima pagina, link base.
Conclusão: Achei o android studio muito ruim para se trabalhar. Na maior parte do tempo fiquei confuso (mesmo seguindo o tutorial), não tinha certeza do que estava fazendo, achei a disposição da informação na tela muito ruim. O fato de ele quase não rodar no PC aqui ajudou muito nessa opinião negativa.
Um ponto positivo é que para dispor os elementos na tela, a ferramenta de GRID dele ajudou bastante, eu tinha certeza de fato do espaçamento e de onde o elemento ia ficar.
Entretanto, além do emulador ser muito ruim, não pude acessar as variáveis dos objetos de maneira mais rápida, sempre tinha que recorrer ao xml e não senti muita segurança modificando as coisas lá.
Mas um ponto positivo é que ao mexer no XML eu tinha a possibilidade de pre-visualizar a mudança, algo que não pude no xamarin, então não precisei ficar indo e voltando no design e código.
No geral, achei o android studio muito travadão, ele não era intuitivo em nada. Até pra colocar uma imagem, que no xamarin bastava eu arrastar, eu tive que dar vários clicks até acertar como importá-la no projeto e onde/como utilizá-la.
- 5.5.16 - 7:03:00 PM
- 0 Comments
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:
Links para vídeos:
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:
Links para vídeos:
- - 6:39:00 PM
- 0 Comments