31 dias: pausa

ocorreram algumas coisas que me farão ficar provavelmente sem postar evoluções, esta semana.

Advertisements

36 dias: ainda tentando (re)entender o problema

Por que fazer o que precisa ser feito é tão difícil? >.<‘

—————————————————————————

Me sinto ingênua quando encaro meu tema como melhorar a usabilidade de engenhos de busca. Mesmo que sejam de propósito específico. Se não consigo fechar bem o escopo, sinto que estou querendo “competir” com equipes de engenheiros e designers especializados em usabilidade, de empresas como a Google, em um TCC feito em menos de um semestre, por uma pessoa. Dito assim, soa ridículo e absurdo. Isto posto, como posso abordar a questão sem que pareça que sou: a) boba ou b) presunçosa?

Conversei um pouco sobre isso com Bruno e dois pontos importantes surgiram (essas conversas são tensas e beiram à discussão, na maior parte das vezes, mas quando sobrevivemos os frutos costumam ser positivos):

  • é importante, dentro do contexto de um trabalho acadêmico, que o problema abordado seja generalizável, no sentido que, de algum modo, é preciso que o trabalho gere um conhecimento que pode ser aplicável por outra pessoa. Isto reforça o ponto de que eu preciso de algum modo entender o que há de genérico ou mais universal no problema que visualizamos na usabilidade do fazDelivery, se quiser que isto seja de fato meu TCC;
  • seguindo esta linha de pensando, e baseados um pouco no feeling que descrevi aí em baixo, sobre o fazDelivery ser um buscador diferente do Google, Bruno sugeriu descrevê-lo ou caracterizá-lo e, portanto, ao projeto que será feito, nos termos de um buscador para uma base de dados estruturados – em oposição a um buscador web. Creio que desenvolver este pensamento pode levar a um problema de pesquisa – ou a uma caracterização do que quero fazer – melhor. E provavelmente vai me ajudar na sequência do trabalho, também, claro.

Além desses pontos, que explorarei amanhã para reencontrar meu rumo, lendo a introdução de Merčun entendi melhor como posso deixar mais claro em minha própria introdução o que é o problema (quando o encontrar!). Ok, espero que estes pequenos passos realmente sirvam para eu sair dessa baixa em que entrei nestes últimos dias.

—————————— More thoughts ———————————————

A sugestão de João para abordar a questão de refinar o problema foi: pensar quais os resultados esperados deste projeto? A partir daí, pode ficar mais fácil entender o que estou tentando resolver. Deste ponto de vista, ocorre-me:

Existem diretrizes para construção de interfaces de busca (como Hearst e Wilson falam, e Merčun também, creio). O que disso se encontra em português? Uma compilação de tais diretrizes poderia ser um subproduto do projeto, desde que bem feita. Mas, dada a natureza do curso de Sistemas de Informação, creio que só poderia ser um fruto secundário, não a meta principal do trabalho.

Se eu procurar por diretrizes para construção de coleções de informação? Sistemas bibliográficos (alvo de Merčun) são considerados coleções de informação? Caso sim, como posso relacionar isto com o trabalho? Preciso:

  1. entender o que é uma coleção de informação;
  2. entender melhor o conceito de buscador web (desconfio que seja, realmente um engenho de busca que enderece toda a web, de modo amplo, ou que no mínimo não tenha um formato específico de formato de resultado);
  3. entender o que é um sistema bibliográfico;
  4. talvez mais importante que os três acima: existem diretrizes para construção de buscadores sobre bases de dados estruturadas? Posso caracterizar o fazDelivery desse modo? Como fazê-lo?

Isto porque, como comentei mais ali em cima, algo está coçando em minha cabeça me dizendo que o fazDelivery é diferente do Google, e talvez mesmo do Yummly, visto que ele contém páginas próprias que visam conter a informação buscada pelos usuários.

Pesquisando sobre coleções de informação, encontrei um blog, que tem uma série de posts sobre mecanismos de busca, nos quais Derek Sisson tenta entender e descrever melhor o que são mecanismos e processos de busca: http://philosophe.com/search_topics/

Pode não ser um documento canônico ou adequado para figurar como uma referência para o TCC, mas está me ajudando a refletir, então, neste estágio do projeto, em que estou tendo que voltar a pensar em qual o problema que pretendo resolver e aonde quero chegar, estou o considerando útil. Destaques que me trazem algum tipo de insight, retirados do post sobre Tipos de Coleções de Informação:

“a collection of web pages is just another type of document collection”

“scope of the catalogue

Whereas any web search engine will only have indexed a portion of existing web pages, any product catalogue is by definition a complete listing of every product in the particular system.”

39 dias: leituras rápidas

Por que pode ser interessante conduzir testes de usabilidade remotos? Remote usability tests: moderated and unmoderated, por Amy Schade:

Remote usability sessions don’t require either the participant or the facilitator to travel. As such, remote testing is a great solution for teams with limited budget, or for testing products whose users are geographically dispersed. Scheduling a series of online studies can be preferable and far less costly than traveling around the country or the world.

It is also a good solution in a tight timeframe— travel doesn’t have to be coordinated, and facilities for testing don’t have to be secured. Further, participants can be from any geographic area rather than concentrated in one location, which can make recruiting faster and easier.

Copiando isto porque eventualmente pode ser útil para o projeto conduzir alguns testes remotos, para aumentar a quantidade de avaliações feitas…

Outro, para não esquecer: usuários tendem a ignorar elementos que lembram anúncios. O que isso quer dizer? No caso do fazDelivery, por exemplo, que temos de tomar cuidado com nossas sugestões de estabelecimentos, porque senão o tiro pode sair pela culatra, e algo cujo objetivo era aumentar visitações pode passar em branco para a maior parte dos visitantes (tópico abordado uma vez mais pelo Nielsen Norman group no artigo Fight Against “Right-rail Blindness”, de Hoa Loranger).

39 dias: HCI e – qual é o meu problema?

Comecei um curso de Interação Humano Computador pela UC San Diego (https://class.coursera.org/hci-004/class/index), no Coursera. Inscrevi-me porque considerei que seria uma abordagem interessante para aumentar os conhecimentos necessários pro projeto de TCC. O curso termina dia 9 de dezembro. Creio que valéra.

Algumas anotações, das vídeo-aulas das duas primeiras semanas:

A meta da prototipação é… feedback.

Focus on goals. Evolve the design.

What do prototypes prototype?

Feel

Implementation

Role

Se protótipos são perguntas, faça muitas!!

——————————————————

Aspectos a considerar no momento de escolher o(s) método(s) de avaliação de interface:

  • confiabilidade / precisão
  • generalização
  • realismo
  • capacidade de comparação
  • quantidade de trabalho envolvido

=> O que você quer aprender?

——————————————————

O que se pode aprender através da observação participativa (participant observation)?

  1. What do people do now?
  2. What values and goals do people have?
  3. How are these particular activities embedded in a larger ecology?
  4. Similarities and differences across people?
  5. … And other types of context, like time of the day

To learn more: Kuniavsky – Observing the user experience. Beyer and Holtzblatt – Contextual design

——————————————————

Entrevistas:

Escolha dos participantes

  • representantes dos usuários-alvo
  • podem ser usuários de um sistema similar (caso, por exemplo, se esteja querendo criar uma versão melhor de algo)
  • podem ser não usuários, caso a ideia seja aumentar o público alvo de um determinado tipo de software

——————————————————

Outcome of activity analysis:

  • what are the steps?
  • what are the artifacts?
  • what are the goals (how you’ll measure success)?
  • what are the pain points (or opportunities)?

——————————————————

O tradicional “projeto final” do curso, que foca em avaliar na prática os estudantes, é para desenvolver um protótipo de interface funcional, para um software baseado na web ou mobile, desde o momento de observar usuários para encontrar um problema real, passando por diversos níveis de prototipação, avaliação com usuários e iterações. Estou pensando em mesclar os direcionamentos do projeto lá para me ajudar na metodologia de melhoria da interface do fazDelivery, também.

Enquanto isso, preciso repensar e refinar meu problema de pesquisa, voltar a escrever a monografia e começar a prototipar e/ou avaliar as interfaces atuais, porque sei que haverá muito feedback dos orientadores neste ponto também…

44 dias: detalhar problema, solução (e metodologia?)

Ok, eu preciso definir, com mais clareza, qual o problema do fazDelivery que pretendo resolver, no projeto de TCC. E também qual a solução que proponho. O que sei/sabemos no fazDelivery é que pessoas para quem divulgamos o site e que observamos (ou não) usando, com ou sem explicações do que se tratava o sistema, reportaram alguns problemas de compreensão de qual era o propósito do site, ou o que poderiam encontrar lá ou mesmo como buscar – temos as mais sérias desses reclamações guardadas, desconfio, neste momento, que posso – e devo – recuperá-las.

Para saber se poderia citar essas experiências, li o artigo de Nielsen sobre Discount Usability. Na verdade, uma espécie de auto-análise deste movimento, após 20 anos do artigo (que é de 1989) em que ele propõe esta metodologia: http://www.nngroup.com/articles/discount-usability-20-years/.

Em linhas muito gerais, a ideia é que é possível conseguir resultados e melhorias de usabilidade muito boas com recursos simples, como prototipagem de papel; avaliação heurística e estudos qualitativos, com testes de usabilidade iterados com cerca de 5 usuários.

Um trecho que me chamou a atenção – porque posso tentar avaliar se tenho condições de conduzir testes de usabilidade com o limite de tempo que tenho – foi onde ele fala dos resultados que conseguiu, com essa abordagem, à epoca do artigo:

For the bank account project, I tested 8 different versions of the design; in the IRA project, I tested 11 different versions. These extensive iterations were completed in 90 hours in the first case and 60 hours in the second. Both projects had great results and were possible only with discount methods.

Discount usability often gives better results than deluxe usability because its methods drive an emphasis on early and rapid iteration with frequent usability input.

Creio que preciso perguntar aos orientadores se posso usar os feedbacks iniciais de nossos usuários como justificativa para o problema no fazDelivery – com base na sugestão de Discount Usability de Nielsen, por exemplo. E, a partir daí, avançar…

[LaTeX] Adicionar data de acesso a referências (ABNTeX2)

Estou citando alguns sites, mas estava esquecendo de acrescentar a data de acesso (importantíssimo quando buscadores não tão conhecidos, por exemplo, morrem todos os dias). Pesquisei em inglês e encrontei que, usando as entradas @online ou @misc é possível acrescentar uma data com urldate. Este campo, entretanto, não estava sendo interpretado pelo LaTeX + ABTeX2 por aqui. Pesquisei novamente e encontrei o campo urlaccessdate, também para a entrada @online. Assim funciona.

O formato da data, pro Brasil fica 09.10.2013, mesmo. Quer dizer, eu li que era sem os zeros. Mas prefiro com. Se não reclamarem, ficará assim.

Fontes:
p.s.: voltando a postar coisas de LaTeX por aqui pois volta e meia tenho dificuldade de encontrar as informações, então parece-me uma boa ideia compartilhar as soluções que encontro…

46 dias: técnica dos pomodoros ajudando

25 minutos focada. Depois, 5 de descanso. Falei no post anterior que ia tentar usar a técnica de pomodoros hoje, para ver se conseguia render melhor. Baixei o TeamViz, que provê uma interface para aplicar a abordagem Get Things Done, além dos pomodoros, e planejei o que ia fazer.

Não consegui ficar focada o tempo todo, mas a ideia de que eu precisava não mudar de tarefa por apenas 25 minutos funcionou em muitos momentos para que eu não trocasse de abas para conversar ou ler ou trocar de música – ou qualquer outra ação que, repetida ou alternada várias vezes, sempre me impede de entrar a fundo em alguma tarefa. Consegui pensar “Quando vierem os 5 minutos eu faço isso” e manter a atenção no trabalho na maior parte dos pomodoros feitos.

Qual o resultado disso? Finalmente consegui rever meu índice, pensar mais detalhadamente o que cada seção do trabalho deve conter, e acrescentar algumas referências mais que creio que irei utilizar, e consegui enviar isto para orientadores e professores da disciplina. Assim, tenho chances de receber feedback, mas, se não receber, tenho uma certa ideia de por onde prosseguir.

That’s it. Amanhã terei de sair de casa, o que tem bagunçado os dias, sempre que acontece, mas vou buscar otimizar o tempo que sobrar com os pomodoros. A tirar por hoje, deve funcionar. 🙂

46 dias: atrasos

Atrasados:

  • referencial teórico;
  • trabalhos relacionados;
  • requisitos funcionais e não funcionais;
  • arquitetura (a princípio estava em dúvida sobre o que faria aqui, mas creio que posso descrever a arquitetura do fazDelivery e indicar onde meu trabalho se insere).

O que farei hoje:

  • baixar contador do tipo Pomodoro – Bruno disse que tem sido muito útil pra ele e meu principal problema é manter foco, então, vamos nessa – 15 minutos (contando colocar tarefas nele);
  • recarregar as variáveis (é vergonhoso ter de dizer isso, mas agora não é o momento de perder com autopiedade): ler antoprojeto e embrião da monografia – 1 pomodoro (contando possíveis anotações que surjam, mas nada de execuções);
  • criar um novo índice – creio que me basearei muito no que fiz pra apresentação, então 1 pomodoro;
  • escrever página descrevendo cada tópico do índice – sendo uma pequena frase, se fizer focada, creio que 1 pomodoro dê;
  • rever cronograma – ver o que estava no anteprojeto, mais as datas de TCC II (e I) – 1 pomodoro;
  • entrar em contato com orientadores e orientadora – 1 pomodoro.

Isso dá: 5 pomodoros e meio. Cada pomodoro tem 25 minutos, mais 5 minutos de intervalo curto e um intervalo de 30 minutos a cada 4 pomodoros, ou seja: isso daria 3 horas de trabalho focado. Contando que estou no processo, já, terminaria antes das 15 h. Talvez almoce no meio do caminho. Anyway, o plano inicial é: fazer esses, e então planejar quais serão as atividades seguintes. Se eu não for pra natação hoje, dá pra trabalhar até 21:00, 22:00, o que seriam mais no mínimo 5 horas de trabalho, o que dá 8 pomodoros. Confere? Let’s get going.

51 dias: nothing new

Não fiz nada ontem. É f*** dizer isso, e saber que me permito fazer isso. A questão da disciplina é complicadíssima pra mim.

Acho que amanhã consigo melhorar. Preciso conseguir, anyway, se quero terminar isso, certo?

Gotta move on…

p.s.: só deixei aqui registrado para isso: ter o registro. Melhor saber que as coisas foram assim para ter uma noção clara do que anda acontecendo.

52 dias: Que história eu preciso contar? Ou: será que contar histórias ajuda?

Tudo começa mais ou menos assim…

Eu trabalho (ou trabalhava) no fazDelivery, que é um buscador de deliveries. Ele tem um motor de busca muito bem planejado, mas sua interface, apesar de ter contado com algum nível de cuidado no que diz respeito à usabilidade, não foi de fato construída por especialistas, nem foi completamente desenhada com foco nas necessidades do usuário (o que poderia reduzir a necessidade de um especialista, já que as pessoas naturalmente indicariam “o caminho das pedras” do funciona melhor para elas quando estão buscando por serviços de pronta entrega).

Quero melhorar a usabilidade do fazDelivery, pois tenho a hipótese de que isto aumentaria sua aceitação e uso – porque diminuiria seu bounce rate (i.e., a taxa de pessoas que entram e saem da página logo depois, por acharem que ela não é o que desejam).

(more…)