Roboto vs. Helvetica

Roboto vs. Helvetica

Estava procurando as diferenças entre as fontes Helvetica e Roboto, e encontrei essa imagem. Cool. =)

Serviu bem para o propósito – pude observar a face no fazDelivery e saber que definitivamente não é a Helvetica. Possível que seja realmente a Roboto, como algumas partes do CSS querem indicar…

Advertisements

Reflexões: escrever aos poucos, ao longo do processo

O fato de eu ir escrevendo na medida em que vou decidindo o que fazer, mesmo que por vezes me faça pensar que estou evitando entrar em algumas tarefas, geralmente me ajuda a refletir muito mais sobre o que estou fazendo, de modo que consigo entender mais o que estou planejando, e tenho mais chances, assim, de avaliar se estou fazendo a coisa certa, tomando as decisões certas, seguindo o caminho certo…

Ou, mesmo que eu não consiga seguir o melhor caminho, ao menos eu posso tentar entender por que não estou seguindo. Se a justificativa for razoável, então eu sigo (:

Exemplo desse processo, hoje: mais cedo, comentei que começaria a prototipar hoje. Entretanto, no processo de analisar como iFood, GuiaMais e TeleListas resolviam as coisas que estava com problemas no fazDelivery, gerei umas tabelas que queria passar logo pro LaTeX. Quando fiz isso, percebi que precisava reestruturar o capítulo sobre prototipação, para encaixar cada coisa em seu devido lugar e dar uma noção da ordem lógica que segui. E, quando fiz isso, percebi que eu não podia já ter proposto soluções antes de ter olhado os concorrentes – mas foi o que aconteceu. Então, amanhã vou revisar as soluções que tinha proposto, comparando com as das outras ferramentas.

[Andamento] Soluções para os Problemas Identificados

Primeiro, uma observação: a palavra que passei os últimos dias tentando lembrar (até ontem, anyways), para descrever o que sinto que faltou na condução da etapa prática do TCC é… rigor. Sinto que fui pouco rigorosa, principalmente na etapa de testes de usuários como um todo. Tinha pouca (quase nenhuma) experiência prática nesse quesito, e ainda assim planejei e conduzi tudo muito sozinha, o que também não ajudou. =/
No último capítulo, comentei que estava em dúvida entre prototipar ou implementar as soluções pensadas para os problemas. Pedi orientação sobre isso para orientadores e alguns amigos. João Rocha disse que preferia que eu implementasse e fizesse os testes com usuários; EJ sugere que eu faça apenas prototipação e comparação das duas interfaces (porque implementar em si pode trazer complicações extras, erros etc, que tirariam o foco no projeto). Entendo e consigo concordar com os dois pontos de vista. Fazer a implementação mais testes deixaria o projeto mais completo, porque teria seguido todas as etapas previstas pela metodologia que eu mesma apresentei. Mas isso reduz meu tempo de trabalho na prototipação em si, o que também tira qualidade do projeto. Então estava meio “dilemética”.
Ontem então pensei em um meio termo assim:
  • v-1.0: corrigir coisas em protótipo. Possível abordagem mista: selecionar os 10 problemas mais prioritários das avaliações heurísticas, mais os problemas dos testes de usuários. Corrigir.
  • v-1.1: Tendo tempo, implementar e testar;
  • v-2.0: sobrando tempo: corrigir em protótipo demais violações de heurísticas.

Está se encaminhando para eu conseguir fazer a v-1.0. Hoje terminei de descrever como três ferramentas correlatas abordam aspectos considerados problemáticos no fazDelivery. A tabela abaixo mostra uma parte dessa listagem (os Ids servem para identificar a que problema cada linha da tabela se refere – ok, sei que está ruim visualizá-la). Hoje, então, parto pra selecionar as soluções que de fato usarei e prototipá-las…

Excerto do levantamento de soluções correlatas.

Excerto do levantamento de soluções correlatas.

Crianças reagem a… computadores pessoais antigos

Bom, já não são mais aqueles negócios que ocupavam salas inteiras e recebiam comandos através de válvulas (ou resistores? >.<‘). Mas ainda assim, pra quem nasceu na era do iPhone, ter um monstrengo para só poder executar comandos simples, através do teclado, em uma tela verde é realmente bastante estranho… A gente acaba se esquecendo que a capacidade de processamento, de memória, da miniaturização e tudo isso não foram sempre como as temos hoje…

Nem serão, nem serão…

Andamento, observações, redefinição de escopo…

Acabo de enviar uma versão parcial (semi-final) para os orientadores. Agora ficam faltando dois ou três capítulos, sendo que a prototipação das melhorias está nesse meio >.<‘

Algumas questões que ainda persistem, pra mim:

  • Devo apresentar todos os resultados dos testes? Sim, apresentei tanta coisa… O.o’ Precisarei compilar individualmente cada um e acrescentar nos apêndices, de algum modo;
  • Está fazendo falta ter uma listagem de todas as heurísticas violadas. Creio que eu mesma imporei como uma obrigação ter isso para a versão final;
  • Em relação aos testes com usuários, além das tarefas e tempos, tenho de acrescentar no tcc uma listagem dos problemas e dificuldades encontrados. Na verdade, no meu caso, isso é o mais importante, dos testes.

Após as dificuldades que tive hoje para sintetizar e descrever os resultados dos testes de usuários, estou pensando em reduzir o escopo do projeto, evitando implementar de fato a interface e, por conseguinte, a nova rodada de testes de usuários que eu precisaria fazer. EJ perguntou qual seria minha abordagem em relação a isso sábado passado e comentei que iria implementar, mas agora prefiro evitar, e visto que ele levantou a possibilidade, estou esperançosa com a resposta…

Eu acho que tinha mais alguma coisa pra dizer, mas esqueci. Ah, o título provisório está assim, agora: Inspeção e Evolução da Usabilidade de Buscadores Tipo Catálogo: Estudo de Caso com o fazDelivery.

Testes com Usuários – O que é importante sintetizar? D:

Ok, eu tenho uma cacetada de informação relacionada aos testes com usuários. E agora, eu uso o quê, o como? Calculei um bocado de médias, defini metas, fiz teste eu mesma, para servir de benchmarking. Mas agora é hora de descrever os testes, apresentar tais dados, extrair algo de valor deles. comofas/ >.<‘

Já descrevi a parte aberta, subjetiva dos testes. Ainda não caracterizei o perfil dos usuários, por outro lado, nem… consigo usar os números de um jeito que faça sentido. Vamos tentar aqui, primeiro. Menos pressão. Por exemplo, eu defini duas metas:

  • consultas não demorarem mais de 3 minutos;
  • 80% das consultas serem concluídas com sucesso (a definição de sucesso era conseguir encontrar um telefone para um estabelecimento que tivesse o produto pesquisado).

A partir dos dados coletados, é possível observar que aproximadamente 90% das consultas foi concluída em menos de 3 minutos (a média foi 1:29 minutos). Entretanto, isso não impediu que apenas 66% das tarefas fosse considerado concluído com sucesso, e em verdade as médias de duração de tarefas concluídas com sucesso ou abortadas porque o usuário chegou a seu limiar de frustração (1:31 minutos) teve uma diferença de 2 segundos, apenas. Isso pode sugerir duas coisas:

  1. o tempo de duração da consulta não é tão relevante para as pessoas, conquanto que elas não se sintam frustradas com o sistema;
  2. ou, seguindo uma linha oposta, que as pessoas têm uma expectativa de encontrar as coisas muito rápido, o que faria com que 2 segundos fosse um tempo significativo, aqui.

A segunda hipótese, entretanto, não é confirmada pelos dados, pois apenas uma das tarefas concluída sem sucesso de fato ultrapassou os três minutos. A partir disso fico inclinada a pensar que a primeira hipótese é a que faz mais sentido, e que, conquanto o sistema não pareça ser incapaz de atender às demandas dos usuários, o tempo de duração de uma consulta (pelo menos no intervalo de tempos destes testes, em que a consulta mais longa levou 4:10 para ser concluída – com sucesso, por sinal) não é tão relevante para a satisfação do usuário com a ferramenta.

Outro aspecto que observei a partir dos testes foi que algumas pessoas consideraram uma tarefa concluída, mesmo tendo encontrado um estabelecimento diferente do solicitado.

Como tais observações são úteis para o projeto?

  1. tenho mais maturidade para pensar as próximas metas;
  2. fica claro que devo observar, das sessões de testes, os aspectos que mais levaram a frustração, para tentar minimizá-los;
  3. a listagem de resultados não é exatamente eficiente para apresentar informações sobre os estabelecimentos (as marcas são pequenas, o nome tem pouco destaque).

Hm. Ok. Isso me ajuda a me sentir um pouco melhor. Essa é uma história que sinto que consigo contar, que faz sentido dentro de meu processo. Agora vou pedalar, pra ajeitar o juízo e as ideias, e volto pra terminar essa descrição da 1ª rodada de testes com usuários.

EDIT 1: ontem à noite, em algum momento, quando reli isso, não gostei muito do racional. Me pareceu precipitado e errôneo. Talvez não tanto por ele em si, mas porque analisei os dados em mais detalhes e vi que quando baixei a linha de corte para 1:29, que foi a média, o racional parou de fazer sentido at all. Acho que só por “diversão” vou calcular a mediana das durações, depois.

EDIT 2: ok, calculei a mediana de todas as tarefas de consulta: 78.5. A média é 89. O que eu deveria conseguir apreender, disso?

Receios, Dúvidas y otras cositas más

Algumas observações meio soltas, após este dia de escrita.

Em relação aos testes com usuário que fiz até então, tenho receios de que sejam muito frágeis os pontos:

  • Perfil dos usuários;
  • Tamanho da amostra.

Estava em dúvida se deveria listar todos os problemas classificados em relação ao grau de severidade. Entretanto, após criar uma tabela com dez deles e ver o tamanho que ocupou, considerei que era melhor não fazê-lo. Acrescentei, no entanto, o resumo da classificação de severidade do questionário do docs, assim, as informações estão todas lá (e o processo que eu usei para chegar às médias também, então se alguém precisar, ou quiser, pode estendê-lo e ter todos os valores). Com isso, tenho uma primeira versão final da seção que descreve o percurso das avaliações heurísticas…

Observações soltas:

  • eu amo o Google Docs – muito bom ter opção de gerar impressão bonitinha de um formulário online…
  • às vezes me pergunto se o tempo que ganho não precisando formatar o documento no LaTeX não é todo perdido ajeitando tabelas no mesmo… >.<‘

Já comentei aqui que tenho receio de meu TCC estar fraco/ pobre? Caso não, estou comentando agora. Estou evitando pensar nisso, e só seguindo, e explicando meu processo e minhas decisões o melhor que posso, para agregar o máximo de valor possível. Mas, por vezes, a sensação volta, e é ruim. E, dito isto, me lembro que já falei disso, sim.

Apoio moral

Apoio moral

Apoio moral de gato é um negócio meio ambíguo >.<‘

Andamento: vamos que vamos

Nova possibilidade de título: Inspeção e Evolução da Usabilidade de Interfaces de Buscadores Tipo Catálogo, Estudo de Caso com uma Ferramenta Georreferenciada de Busca de Deliveries acho que é bem realista ‘-‘. Mas coloquei no TeX e compilei e ficou enorme e uma droga. Pensar em outra coisa.

Fui falar pessoalmente com EJ. Ele deu pontuou algumas coisas, fez contribuições realmente interessantes – gostaria que isso tivesse acontecido antes, mas paciência. Apesar das questões levantadas e de discordar de algumas decisões, considera que dá pra apresentar o TCC dia 14. Só preciso conseguir gerar uma versão da mono para ele e João revisarem, ainda essa semana, e corrigir a interface para poder testá-la entre quinta e domingo. E fazer o resto que falta.

Antes de ir lá tinha feito uma outra versão da metodologia, junto com uma descrição mais detalhada e atualizada, e mudei a figura. Após a conversa surigiram mais mudanças a serem feitas. Estou trabalhando nelas agora. Uma dúvida que me surgiu, é: com que granularidade devo (ou deveria) apresentar as coisas, na figura da metodologia?

Estou lutando com meu eu crítico me dizendo que o TCC está muito simples/ pobre… Se eu fosse postergar sua entrega, corrigiria os problemas que puxei para serem classificados na avaliação heurística, daí seguiria o processo primeiramente definido, aproveitando para filmar os testes, que foi algo que EJ pediu. E tentaria fazer mais apropriadamente o processo de prototipação e implementação. Vamos ver o que vai dar pra fazer, com o que tenho.

Ocorreu-me agora há pouco que posso justificar a escolha de problemas escolhidos nas avaliações heurísticas como um recorte da lista completa, para tornar o projeto mais factível dentro de suas limitações. O recorte escolhido, no caso, foi relacionado a aspectos que poderiam levar a erros no fluxo dos usuários, porque a ferramenta entrou em estágio de manutenção (i.e., saiu de evolução e desenvolvimento) ainda com muitas coisas a serem corrigidas.

[LaTeX] Para incluir páginas de arquivos em pdf em seu arquivo TeX

Preciso anexar Roteiros, Questionários, Termos de Consentimento e essas coisas à monografia. O caminho que funcionou para mim foi usando o pacote pdfpages:

\usepackage{pdfpages}
\includepdf{arquivo.pdf} % incluirá o arquivo todo

Se você precisa que o arquivo fique dentro de uma seção, precisa complementar o comando, do contrário uma página extra, em branco, será inserida e vai bagunçar a estética de sua seção, capítulo ou apêndice (meu caso). Aí embaixo estou fazendo o seguinte: no primeiro comando, peço para incluir apenas a primeira página do pdf, reduzindo seu tamanho, para caber também o título do Apêndice. No segundo comando, insiro as páginas restantes de meu roteiro.

% note o comando para criar seção ou capítulo (pagecommand)
\includepdf[scale=0.87,pages=1,pagecommand=\chapter{Roteiro}]{Paper.pdf}
\includepdf[pages={2-5}]{./anexos/RoteiroAvHeuristica.pdf}

E é isso! Essa segunda parte, para reduzir tamanhos e inserir o pdf sem uma página em branco foi encontrada no TexExchange.