The consequences of choose an item in a picker is not obvious

[Curtis Hovey]

New users to Lp report that they were surprised that choosing a item such as a user would close the picker and assign the user. When assigning a user to a bug, the user sees a link to assign himself. The action is explicit, it sets the expectation that the rest of the picker is explicit. The users imagined that choosing a user in the list would reveal more information about the user and a link to assign the user.

[Martin Pool (mbp)]

I think this would be a really good thing to specify in the ui style
guide, so it can at least trend towards being consistent everywhere.
At the moment it is not: consider the assignee picker vs the filebug
suggestions vs retarget to vs ...

Something like "when we should a list of objects from which the user
is going to pick on (eg as a bug target project or a bug assignee
person), we should show them as radiobuttons with a separate submit
button" or "... we show them as list items where clicking one item
immediately selects it" or whatever.

[Huw Wilkins (huwshimi)]

@mbp
That's a really good idea. Curtis and I have spent a bit of time trying to figure out what is best in this situation and hopefully whatever we go with can become the standard.

[j.c.sackett (jcsackett)]

I've put together videos of an expander concept that may address this. They can be seen at http://people.canonical.com/~jc/videos/picker-expander/

[Martin Pool (mbp)]

Thanks very much for the videos! Here are a few thoughts:

 * Expanders seem finicky given you're just showing a couple more
words or often nothing more at all. Why not just always show the
person's relevant affiliations? If we want to avoid people
accidentally assigning to the wrong person it seems pretty important
it be easy to just notice this.

 * Needing to expand to select someone seems like a step backwards:
one more click, and not especially accomplishing much.

 * Text saying "click to select" is pretty odd (to put it politely) in
a web application. Normally you would click on the object you want to
select, or click on a radiobutton or similar control next to it.

 * A specific consquence of "click to select" is that the active area
you have to hit is relatively small and doesn't have a clear boundary.

 * Some parts of Launchpad are click-to-choose, and some are
click-to-select and then you separately submit the choice. It would
be nicer to really solve that.

 * It seems a bit redundant to have a text field with a link next to
it that brings up a popup with another text field that does
essentially the same thing.

Following mpt's suggestion of considering multiple solutions, another would be:

Get rid of the 'choose' link and the popup window. Let people type in
the person field directly, and show a drop down menu of matching
names, with the exact match first, and decorated with affiliation,
email, and other information.

Then the typical "I know what I want" is just to type "mpt <enter>"
but along the way I'll get some confirmation it's the right mpt, and
if I have not got it quite right, I can scroll further down the list.

[j.c.sackett (jcsackett)]

> * Expanders seem finicky given you're just showing a couple more
> words or often nothing more at all. Why not just always show the
> person's relevant affiliations? If we want to avoid people
> accidentally assigning to the wrong person it seems pretty important
> it be easy to just notice this.

The affiliation video was just an example of showing more data on
expansion--other options might be "most active in ..." or other data,
depending on what can be passed along. I absolutely agree that expanding
without more data is pointless--the idea per the bug report is to show a
good bit more data if possible. Sorry I didn't find a way to make this
clearer in the video, I was just sort of mocking out what things might
look like.

> * It seems a bit redundant to have a text field with a link next to
> it that brings up a popup with another text field that does
> essentially the same thing.

That may well be true.

> Following mpt's suggestion of considering multiple solutions, another
> would be:
>
> Get rid of the 'choose' link and the popup window. Let people type in
> the person field directly, and show a drop down menu of matching
> names, with the exact match first, and decorated with affiliation,
> email, and other information.

That sounds really cool, actually.

[Huw Wilkins (huwshimi)]

> * It seems a bit redundant to have a text field with a link next to
> it that brings up a popup with another text field that does
> essentially the same thing.

From a previous discussion we were talking about removing that field altogether and replacing it with just the result. Having an input field that gets populated from the picker does not give confidence that you've actually selected the correct person, especially if what is entered into that field is not what you might see in the picker (you might click on "Huw Wilkins" and the input is populated with "huwshimi").

> Get rid of the 'choose' link and the popup window. Let people type in
> the person field directly, and show a drop down menu of matching
> names, with the exact match first, and decorated with affiliation,
> email, and other information.

I think we also talked about that being too costly performance-wise at this point. We also return to the problem of people often requiring quite a bit of information to make a decision about who to select.

[Curtis Hovey (sinzui)]

@huwshimi
> (you might click on "Huw Wilkins" and the input is populated with "huwshimi").

We do show the Lp-id in the picker, so the user is picking the huwshimi text.

I put some thought to this. I think the ideal scenario would be to show the same user/object presentation in the form:
    Assignee: @Huw Wilkin (huwshimi) (/)
The real field is hidden; it still gets the Lp-Id that the current UI shows.

For an empty field I would see:
    Assignee: None (/)

Making the input field hidden for a picker is simple, maybe a few lines of code. I do not know what we show in the page where the field was, and I cannot judge the effort to show formatted values for picker choices in a form. Maybe this is a simple as setting the title of the term (the value converted to a term) to the desired markup instead of using the Lp-id. I cannot say this is in scope. Have users reported that they do not connect the Lp-id in the picker to the Lp-id in the field?

[Huw Wilkins (huwshimi)]

> I put some thought to this. I think the ideal scenario would be to show the same user/object presentation in the form:

That's pretty much what I had in mind. We do this with the Assigned to field on a bug.

> Have users reported that they do not connect the Lp-id in the picker to the Lp-id in the field?

I have not spoken to anyone since the full name and id were visible in the picker, but certainly before that change this was a much bigger issue.

[Robert Collins (lifeless)]

Re:
>> Get rid of the 'choose' link and the popup window. Let people type in
>> the person field directly, and show a drop down menu of matching
>> names, with the exact match first, and decorated with affiliation,
>> email, and other information.

>I think we also talked about that being too costly performance-wise at this point. We also return to the problem of people often
> requiring quite a bit of information to make a decision about who to select.

Its certainly possible to to type-ahead lookups efficiently. We'd have a few considerations to take into account, like client->server latency, rate limiting the searches, and possibly pregenerating some key situations (like single-letter completions [for single-letter vocabulary entries]).

Anyhow, if we want to do it UI wise, I'd be delighted to help whichever team is working on it achieve a good result doing it. I couldn't estimate the work right now because we're lacking a brief/LEP.

[Martin Pool (mbp)]

> >From a previous discussion we were talking about removing that field
> altogether and replacing it with just the result. Having an input field
> that gets populated from the picker does not give confidence that you've
> actually selected the correct person, especially if what is entered into
> that field is not what you might see in the picker (you might click on
> "Huw Wilkins" and the input is populated with "huwshimi").
>
>> Get rid of the 'choose' link and the popup window. Let people type in
>> the person field directly, and show a drop down menu of matching
>> names, with the exact match first, and decorated with affiliation,
>> email, and other information.
>
> I think we also talked about that being too costly performance-wise at
> this point.

Of course performance is a concern, but:

If you know you definitely want to assign it to ~mbp, you can just
type that and the autocomplete speed doesn't matter.

If you want 'martin pool' and you don't know the userid, you're going
to have to wait for at least one search in the current dialog, and
doing that search from a dropdown shouldn't need to be any slower.

The dropdown by not having a single explicit user action to initiate a
search might end up with more requests being started and aborted (or
not aborted, and running on pointlessly), and we'd want to make sure
early searches didn't block out later ones. But there is in theory
already client code and patterns to do this efficiently as Robert
says.

> We also return to the problem of people often requiring
> quite a bit of information to make a decision about who to select.

That's a question of whether the information that the LEP says must be
displayed can fit into a reasonably sized dropdown list item? I think
it can; showing too much text is not going to help...

[Curtis Hovey (sinzui)]

We have a UI ready to implement: http://people.canonical.com/~curtis/person-picker/person-picker-0.html

This presentation overlaps with bug 798764 and bug 798759.

 * It is not obvious that "Jonnty" is a team.
  - The red icon caused confusion with the "required person" icon in blueprints.
  - Most people didn't even notice the different colour.
  - The word "Team" next to the name/ID would be easier for people to spot and understand.
  ! We will use the default team icon of course, but we may want to try to append "team" to the team name?
 * The affiliation info is really useful.
 * There was confusion over whether the logo indicated a team or a project affiliation.
   ! This has always been true since teams often reuse project icons :( I think the listing of the project role answers user questions.

The UI implies we know more than the maintain role.

[Martin Pool (mbp)]

The new ui looks pretty nice.

The person icon, arrow, and name are misaligned.

I think using the team icon would be a good hint, and consistent.

As far as the specific bug 800361, this is basically solving it by
taking away the "assign me button". I press that button pretty often,
and I would imagine others do too - you could get data from the logs.
I wonder if losing it and instead inserting a multi-second task to
search for yourself would be considered a functionality regression.

It's not very obvious which parts you can click on to choose a person.

[j.c.sackett (jcsackett)]

> As far as the specific bug 800361, this is basically solving it by
> taking away the "assign me button". I press that button pretty often,
> and I would imagine others do too - you could get data from the logs.
> I wonder if losing it and instead inserting a multi-second task to
> search for yourself would be considered a functionality regression.

I believe this mockup is showing what the picker looks like post search; once you've entered in search data the Assign Me button goes away. When you initially open a person picker, the Assign Me button is available, and I know of no plans to remove it.

[Martin Pool (mbp)]

Oh, I see. That works.

[j.c.sackett (jcsackett)]

I'm unassigning myself from this in case someone else is up for it while I'm dealing with some of the privacy display stuff.

[Launchpad QA Bot (lpqabot)]

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

[Launchpad QA Bot (lpqabot)]

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