person picker isn't clear and unambiguous about the person being picked

[Curtis Hovey]

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 owner/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 owner/driver often takes extra steps to verify the Launchpad Id of the user in the picker. Teams are also ambiguous.

Owner/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 owner/driver that he does not need to investigate the user before picking the user from the list. Owner 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.

[Curtis Hovey (sinzui)]

Some part of Launchpad use this convention:
    User Display Name (~launchpad-id)

The line that shows the primary email address could also show irc nicks.

This the underlying issue identity and affiliation overlaps with bug 81692. The picker could show the project icon next to users who are in a project role (when the picker is in the context of a pillar). Showing team membership icons which are only shown of the user profile page may help.

I believe users will also feel more confident if the matches were sorted by relevancy instead of display name. Exact matches with launchpad-id and email address should score more than matches in unconfirmed data. Users who are affiliated with a project should score better than outside users. Users with karma are more important than those with zero.

[Martin Pool (mbp)]

I think I filed some bugs years ago about this. Showing enough information that you can be confident the user is who you think, and biasing towards revelant users would be great.

One other thing is that entering the user id is often not enough to make that user appear on the first page of listings! That's awful. Matching a user id is not an absolutely reliable guide -- in Launchpad if I type 'curtis' I probably mean ~sinzui not ~curtis -- but it ought to work.

[Alex Chiang (achiang)]

I *think* in comment #1, you are proposing to use the convention of User Display Name (~launchpad-id).

If so, great; if I am using person-picker as a team leader, I know the launchpad-id of my intended victim ;) and seeing it displayed will help me disambiguate the search results, especially if email addresses are hidden (as the often are).

If the proposal is merely to use team or project icons, I don't think it will be sufficient. There are many teams and projects without icons.

Tweaking the search results and how they are displayed is nice from a UX point of view (fewer clicks == mo' better), but the main issue is the ability to disambiguate, which simply isn't possible today if email addresses are hidden.

Thanks.

[Curtis Hovey (sinzui)]

Our current thinking it to show launchpad-id, a badge if the user is affiliated with the current context, preferred email address if it is available, and irc nicks if they are available. We need to test the UI for this because this could be too much information to understand in a glance. If I were to search for sinzui in the launchpad context I might see something like this:

@ Curtis Hovey (~sinzui) (#)
    <email address hidden>
    sinzui@freenode, sinzui@canonical
@ sinzui (~sinzui.not)
    <email address hidden>
    sinzui_@freenode

[Launchpad QA Bot (lpqabot)]

Fixed in stable r13132 <http://bazaar.launchpad.net/~launchpad-pqm/launchpad/stable/revision/13132>.