• Immutable Page
• Info
• Attachments
• More Actions: Raw Text Print View Render as Docbook Delete Cache ------------------------ Check Spelling Like Pages Local Site Map ------------------------ Rename Page Delete Page ------------------------ Subscribe User ------------------------ Remove Spam Revert to this revision Package Pages Sync Pages ------------------------ Load Save SlideShow

Bug subscription mock-up testing June/July 2010

Launchpad's bug notification emails can be a useful way to keep up with bugs that interest you. You can subscribe to individual bugs and to entire projects, packages or parts thereof.

The trouble is, busy bugs generate a lot of email and it can be hard to distinguish what interests you from all the rest.

Graham Binns is working on a new bug subscriptions system that will:

• allow you to choose what sort of information about a bug should trigger an email
• track all of your bug subscriptions on one page
• add a new feature that lets you subscribe to the results of a bug search.

To ensure that the bug subscription process makes sense, Graham and Matthew Revell showed mock-ups of the new designs to nine people who already make frequent use of Launchpad's bug tracker.

The testing took place in two rounds, allowing Graham to adjust the mock-ups based on feedback from the first round.

How it worked

Each session lasted roughly one hour and involved one Launchpad user. Prior to the session, they did not know what the new feature was and nor had they seen any of the mock-ups.

During the session, Graham observed while Matthew showed each mock-up to the person and asked them to imagine how they would accomplish a set of tasks.

Audio and video of each of the sessions were recorded.

Afterwards, Matthew wrote a transcript of each session and drew up a short list of recommendations for how the designs should change. After the first round, Graham used that report to alter the mock-ups in time for round two. Following round two, Graham used those recommendations to alter the design of the actual implementation.

Round 1

The mock-ups

Download all round 1 mock-ups

Subscribing to a package's bugs

Subscribing to a bug search

Editing a subscription

Subscriptions overview page

Recommendations

On the subscribe dialogue box, simply the text but also put the emphasis on "subscribe me", with the option to subscribe someone else being secondary and well explained.

The "Don't send me any notifications..." option confused everyone.

They didn't understand why this would be presented to them when they'd just asked to subscribe and also when there is already a cancel button on the dialogue. They questioned what its behaviour would be. It only made sense to a couple of participants who, after quite some consideration, thought it might enable them to pause a subscription and come back to it later, or perhaps act as a public record of their interest in a project.

We don't, though, have such a place where a public record is made.

We should:

• remove the option entirely
• or remove it from the "new subscription" dialogue but then rename it as "Pause this subscription" on the edit dialogue, which would keep the subscription listed on the user's subscriptions overview page but stop any email until they re-enable the subscription
• or as above but retain it on the new sub dialogue but find a wording that makes more sense than "Pause..." in the context of a new sub.
• Consider expanding what it means to be subscribed -- this doesn't just have to be about bug reports.
• When summarising the search that someone is about to subscribe to, there should be the option to edit the search.
• Subscription overview page: refer to individual bugs to avoid confusion.
• Description of subscribed search should show you what's hidden from your search, such as dupes, as well as you're actively getting.
• Overview page: subscription type must match options they've seen before.
• Overview page: bugs should be individual bugs or ismilar.
• Bug searches: Launchpad should send an email telling you why a bug has dropped out of your search. Should consider making it optional.
• Consider putting search box after "Subscribe me".
• Consider re-wording dialogue box.
• Consider re-ordering sub type options.
• Summarise what you've done in the confirmation message.
• Should the search text be mentionined on the search sub dialogue?
• Use active voice.
• Put subscription info summary on profile page.
• Not "all changes", "every change"
• There's some confusion over whether only administrators can subscribe someone, so we need to change the wording.

Transcripts

Download the transcript (html)

Round 2

The mock-ups

Download all round 2 mock-ups (8.6 MB)

Subscribing to a package's bugs

Subscribing to a bug search

Editing a subscription

Subscriptions overview page

Recommendations

• On the subscription dialogue, skip the first stage with the option to choose either "Subscribe me" or "Subscribe a team". Instead, assume they're subscribing themselves and offer a "Subscribe a team instead" option at the bottom of the dialogue.
• Ensure all of the subscription options are present when subscribing a team.
• Place "Save", "Try search" and "Cancel" options on the "Edit search" page.
• On the subscriptions overview page, consider "100 individual bug subscriptions" to further clarify that these are subscriptions separate from the package, search, project, etc subscriptions.
• Confirmation messages should explicitly state what type of subscription the person has made.

Transcripts

The message from each of the second round participants was sufficiently clear that we could draw our conclusions without a detailed transcript of each interview. The audio and video files will follow, though.