Open Bug 1061755 Opened 10 years ago Updated 2 years ago

Figure out a plan for testing user performance with awesomebar results

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Version:
33 Branch
Platform:
x86
All
Type:
defect
Points:
8

Tracking

()

People

(Reporter: phlsa, Unassigned)

References

Details

We are making lots of changes to the awesomebar right now, and there are new changes in the pipeline. While I think (hope) that we are instrumenting all of this, but it would be good to have a plan ready to do some directed experimentation. We need to answer these questions: - What are our goals with the awesomebar? (e.g. Users typing as little as possible, users navigating as quickly as possible etc.) - How do we measure how we are doing on these goals? - What kinds of experiments, A/B tests etc. can we run to help us move towards those goals?
Flags: firefox-backlog+
Blocks: 583683
Flags: qe-verify-
Points: --- → 8
Bug 775825 may be relevant here.
Assignee: nobody → wselman
The research plan: 1. Create a special build based on prototype in Bug #1040923 2. Test qualitatively with users. Test protocol is already created. 3. Add telemetry probes to measure autocomplete usage.
Depends on: 1040923
No longer depends on: 1040923
Blocks: 1079452
This bug was originally created to test bug 583683. So it was more about question like knowing if the users click on the results that are hidden by the scrollbar or how many entries it is the most efficient to show (with or without a scrollbar).
(In reply to Guillaume C. [:ge3k0s] from comment #3) > This bug was originally created to test bug 583683. So it was more about > question like knowing if the users click on the results that are hidden by > the scrollbar or how many entries it is the most efficient to show (with or > without a scrollbar). We read this bug as more general about changes to the Awesome Bar, not just the optimal average number of non-scroll entries. In discussion, we decided to expand the scope to focus on a larger set of changes. However, we can include a study of this specific research question. Or we can write a separate bug to focus on the specific question of entries. That said, I know that Gregg Lind has been working on this question.
This is a huge topic :) Glad to be involved.

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.

Assignee: wselman → nobody
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.