launchpad development
Trusted pickers
Person and project pickers do not provide enough information to be trusted.
The pickers will provide more information so that the user do not need to investigate the choices that matches the search terms. The matches will be sorted by relevance--exact matches will not be on the second page. This feature relates to
On Launchpad: person-picker, project-picker, package-picker
Rationale
It was discovered during UI testing for "managing disclosure" that users who work with private data do not trust the person picker. When assigning a user to a bug or a project, the maintainer/driver needs to to assured he is selecting to the correct person. The picker often provides nothing more that a display name because the user has hidden email addresses. The maintainer/driver often takes extra steps to verify the Launchpad Id of the user in the picker. Teams are also ambiguous.
maintainer/drivers asked to a field to directly input the assignee's Launchpad Id (the old feature) because they had more confidence in their typing than the picker. The old feature was removed be typos and confusion between Launchpad Id, IRC nick, and email address also caused no confidence.
The picker must always show enough information to the maintainer/driver that he does not need to investigate the user before picking the user from the list. maintainer drivers always need to see Launchpad Id, and often want to see nick. Exact matches on Launchpad Id and nick are expected to be first.
Stakeholders
- PES (Steve Magoun, Cody A.W. Somerville)
- Hardware enablement (Chris Van Hoof, Hugh Blemings)
User stories
Person picker
As a person sharing private data with someone else
I want to be certain that I am sharing with the right person
so that I do not disclose confidential information.
As a maintainer/driver of a project
I want to be certain my choice from a picker is correct
so that I do not disclose confidential information.
Target picker
As a maintainer/driver of a project
I want to be certain my choice from a picker is correct
so that I do not disclose confidential information.
Constraints and Requirements
Must
- The listing of matches must display the same information that can be search on. For example, users can be search by Launchpad-Id, display name, IRC nick, and email address, thus that same information must be show with the matches.
- The matches must show if the user is related to the structural context. Users how are affiliated with a project or distro are more likely to be the user that is being search for. Affiliation may mean maintainer, driver, bug-supervisor, previous bug assignee, etc.
- The matches must be sorted by relevance. Exact matches are expected to be the first matches in the listing.
Nice to have
- Target pickers, well, pickers used to retarget bugs and blueprints display the Launchpad Id, maintainer and project group to assure that the user is not selecting a misleading target.
- Users requested that pickers show a short list of common/previous choices to be shown when the picker displayed. This avoids the long search phase.
Must not
- Require that the user open another browser to investigate the user/project in the listing.
- Must not show the "too many results" message when there are only a few exact matches.
Subfeatures
All pickers use vocabularies. The work implies that vocabularies may need additional selecting and sorting behaviours.
Workflows
A user need to assign to a person or team.
The user search the picker and chooses the match because it shows the exact term he searched for. The user is reassured that he can see the match is affiliated with the project listed in the bread crumbs.A user need to assign to a common person or team.
The user sees his frequent selected listed in the picker so that he does not need to search.
Success
How will we know when we are done?
- A driver can search for a user by Launchpad-Id or IRC nick and see that same information in the listing of matches.
- A driver can search for a user with a hidden email address and can see that the user is affiliated with the project
- A driver can search for a project and be certain which matches are owned by his teams or belong to his project groups.
How will we measure how well we have done?
This is difficult since this enhancement is about reducing the mistakes made while using the pickers.
- Maybe get a measure of how often bug assignees and blueprint roles are changed twice within 2 minutes.
- Maybe there is a record of LOSA requests to unsubscribe users or change maintainers because of a mistaken selection.
