Estou fazendo a avaliação de usabilidade de uma API. O método que estou seguindo é o "think aloud protocol for APIs" - um método baseado na avaliação de usabilidade de interfaces gráficas e que foi modificado para APIs.
Em linhas gerais, este método consiste em observar programadores durante o desenvolvimento de algumas tarefas que usam a API. A parte do Think Aloud é feita pelo programador. Ele verbaliza quais as dificuldades que encontra pelo caminho para escrever o código de determinada tarefa. Este método, portanto, suporta a avaliação qualitativa de APIs, pois a observação do comportamento do programador é uma de suas bases.
No entanto, como eu sempre gosto de extrair números das coisas que estou avaliando, acabei bolando uma métrica baseada na seguinte frase:
"It is the comparison between what developers expect and what the API provides that is interesting when evaluating the usability of an API" (Steven Clarck)
O que eu fiz foi pedir para que os programadores, sem conhecer a API, fizessem o pseudocodigo de determinada tarefa. A partir daí eu faço uma comparação simples entre o número de métodos que o programador esperava que houvesse na API e o número de métodos que realmente estão lá.
É uma métrica simples, mas acredito que podem tornar as coisas menos subjetivas.
Dessa maneira, acabo me aproveitando de todo o apoio do protocolo para avaliação subjetiva e ainda crio uma métrica que pode servir como resultado quantitativo.
O que acham?
6 comentários:
Eu sei que exigir mais esforço do programador pode tornar o estudo não prático, mas que tal seria pedir para o programador fazer um "casamento" entre os métodos de sua API imaginária e a real? A partir disso também você conseguiria extrair alguns dados quantitativos um pouco menos simples simplesmente o número de métodos, olhando para o grafo obtido.
a discussão é no blog ou no reader? =D
dudu,essa é exatamente a idéia da métrica. Ou você não entendeu, ou eu não entendi o que você escreveu :)
A discussão pode ser por aqui mesmo!
o/
Na verdade eu expliquei mal. Quando disse: "eu faço uma comparação simples entre o número de métodos que o programador esperava que houvesse na API e o número de métodos que realmente estão lá." Eu quis dizer: Eu contabilizo quantos dos métodos presentes no pseudocódigo estão na API. A medida é a API tem X% do que o cara espera. Ou seja, eu pego os métodos que ele gostaria que tivesse na API e vejo quantos deles estão presentes nela.
Opa jão, quando eu vi sua idéia eu lembrei imediatamente de recall, que é uma metrica de avaliacao de RI.
http://en.wikipedia.org/wiki/Precision_and_recall
O que eu estava pensando em sugerir era algo + parecido com precision.
Para completar o pensamento, note o que ocorre com a métrica no seguinte exemplo:
Se uma API tem N métodos: 1 método god_like_solve_all_my_problems() e outros N-1 métodos inúteis.
Se o meu pseudocodigo tem M métodos, mas sem qualquer correspondencia com os N-1 metodos inuteis da API real, apenas com o god_like_solve_all_my_problems().
Nesse caso a API tem tudo que o programador necessita, mas não da maneira que o programador espera. Pela sua medida (recall/revocacao), no exemplo acima, o resultado seria 1 - a API tem uma revocação alta (traz tudo que é relevante), mas não tem uma precisão alta (traz coisas irrelevantes junto).
A sugestão é mais para pensar, talvez a precisao nao seja importante, apenas a revocacao ja seja suficiente. =D
Oi João,
Rapidamente, acho difícil ter uma métrica tão objetiva.
Suponha que a API tem dois métodos com mesmo nome, mas um recebe dois parâmetros e outro recebe três. O programador entrevistado só especifica um dos métodos. Como você quantificaria isso na métrica? Dar o mesmo peso de um método bem diferente não me parece bom, outra solução tende a ser mais subjetiva.
Outro ponto. Interfaces em sistemas que cresceram organicamente tendem a ser maiores e, às vezes, com muitos métodos que têm funções parecidas. Como quantificar?
Se o projetista da interface criou o parâmetro Options para capturar as diferenças devido a um crescimento orgânico. Como quantificar as diferenças?
Parecido com o ponto logo acima temos os casos onde o entrevistado não é bom projetista, não conhece o sistema direito etc.
Nesses casos, a métrica poderia ter uma grande diferença, mas não porque a API é difícil de usar.
Que te parece?
Postar um comentário