I'm OK with auto-selecting the first device but I thought there were reasons among the Bluetooth team not to. Do you remember if that was the case?

I think when there is no auto-selecting, if user accidentally press the "PAIR" button, nothing will happen, but when auto-selecting the first device, it will pair the first device even though the user doesn't mean that.

As for the issue of "The "list of devices" doesn't look like a list when there is only one.", how about adding a separator just above the first device, similar to the separator above the "Get help while scanning for devices..."?

I guess the user could accidentally press "PAIR" but they could also accidentally press a lot of our blue buttons (like "Allow" to grant location, camera/mic, notifications etc.) One reason I don't love it is that sometimes the button is active, sometimes not, depending on how many items are in the list.

An extra separator is a good idea if we're really concerned about accidental pairing (or the discrepancy in behavior between one item showing and pair being selected vs. multiple showing and pair not being selected.) Talked with hannahs@ about this and maybe we'd try separators between every item. But we're unsure how that would translate to desktop. Might be better to add checkboxes at that point.

Could we possibly wait to hear the resolution from UI Review on signal strength: https://groups.google.com/a/google.com/forum/#!topic/chrome-ui-review/Drx5nxLdOGo

I bet once there is an icon to the left of the text it would read more as a tappable item:
https://bugs.chromium.org/p/chromium/issues/detail?id=629689#c12

Just depends on whether UI Review goes for it or not.

Here is the screenshot of adding an extra separator between the chooser title and  the first item. It makes the text below the title more like being in a list that can be selected. What do you think?

Deleted: chooser.png 146 KB

	chooser.png 146 KB View Download

Because UI Review is OK with the cell signal strength indicator (for now) could we try that and see if it makes a difference first? I think that's waiting on ortuno@ in a separate bug linked in comment 4.

Let's see if that changes anything. For the record, here's a mock of how it would look like based on ortuno@ screenshot in https://bugs.chromium.org/p/chromium/issues/detail?id=629689#c12

Deleted: one-bluetooth-device-with-rssi-on-android.png 775 KB

	one-bluetooth-device-with-rssi-on-android.png 775 KB View Download

I think whether there is a signal strength icon or not, adding an extra separator between the chooser title and the first item helps. What do you think?

Re: Why not just auto select the 1st: It's confusing if we later have more than one device. Users pressing "Pair" may not notice or understand the list and that they need to make a choice for which item in the list to use.

I do think that the current display doesn't look actionable enough. :( I miss good old ugly radio buttons - which hinted in a familiar way "pick one of these".

The separators help in my opinion. I don't think the cell strength indicators do help with the list understandability.

So, my suggestion would be to include the additional line. /shrug/

Hannahs@ would be the final design vote on visual changes. She brought up using radio buttons/checkboxes. It's not really Material style but if it's something that's not too hard to implement we could consider it. But it would be a MUCH bigger change than just adding a line.

Mostly I (over) worry that introducing a line here is something that doesn't happen elsewhere, across-platform. I'd like us to make sure we're consistent. Considering the dialog will already change with the signal icon (and consequently, better match OS wifi/bluetooth pages) my vote is that we hold off and see if that resolves the issue.

But hannahs@ if the line doesn't bother you, let me know!

I think adding a line is consistent across platforms. Since the desktop chooser already has a boundary box which lists all the items. The boundary box is similar to the two lines here in the Android chooser.

Yeah it might be ok (I'm probably overthinking it.) The desktop boundary box is a dated, pre-Material style so I wouldn't compare 1:1 (we might run into the same desktop issue if the style changes.)

Functionally, the scroll for a long list would need to sit now between the two lines (rooting the title to the top and slways being visible) and we might not want to do that because of small screens (rare use case I know.) I'd also say this line needs to be a couple pixels further away from the text to more closely match the existing distance from the bottom line to the subtext.

hannahs@ - what's your preference?

I updated the line position to have the same distance to the top and bottom text.

Also I uploaded a screenshot showing the scroll is between the two lines when there are many devices in the chooser.

Deleted: chooser_1.png 142 KB

	chooser_1.png 142 KB View Download

Deleted: chooser_2.png 180 KB

	chooser_2.png 180 KB View Download

Great thanks. Looks OK to me. Hannahs@ - what do you think?

I guess we can make this change, right? If so, I will land the CL.

I wanted hannahs@ to weigh in because this is partly a visual issue. There are study sessions going on though so I talked with bettes@ today while hannahs@ is busy.

OK prepare yourselves for what I know is UX Excessivitude. I know it feels this way but it's important for overall brand. Technically doesn't matter a ton; it's just a line. But as far as style, there's not a case I can find where we have a full bleed line under the title before scrolling. (If you know of one, tell me!) The plan for desktop dialogs is to show one after you start but not before (https://folio.googleplex.com/chrome-ux-specs-and-sources/Chrome%20browser%20(MD)/Secondary%20UI%20Previews%20and%20specs%20(exports)/Preview#%2FP%20-%20smartlock_03.png%3Fz=width)

Material spec for dialogs includes two ringtone examples. Under "scrollable content exception" you can see a line appearing under the header after scrolling, but not before (in the "confirmation dialogs" section.)
https://material.io/guidelines/components/dialogs.html#dialogs-behavior


So I'd say:
1) Let's add signal strength first and, if we don't have them already, metrics to see if people are abandoning the dialog more when there is only one item listed. (Is this possible? Metrics would really help.)
2) Loop in your PM to prioritize the problem and request UX support. I'm actually not slated to be doing Bluetooth UI work this quarter, and if we were to fix this it sounds like we might want someone who can really focus on it.

Future options include:
- If it's still an anecdotal issue but we're not sure, we could do lightweight research on it (either log a Google Consumer Survey or a cafe study.)
- Reaching out to the Material group and ask for what to do in these sorts of instances. Perhaps the style needs to be updated.
- Add checkboxes instead of a line (more in the current style, but definitely more work and would require a more thorough review)

Thanks, Ani is PM,

I think the prudent way forward is to run a consumer survey. It's scientific, and can provide good measurable results in a short time.

Experimenting in Chrome is very slow, and I think we'd need to do an A/B test anyway, and it takes more work than spinning up mocks.

I can help jun design and run a survey. rolfe, if you have any particular thoughts or requests for how we do that please let me know. Briefly thinking about it I'd generate 4 mocks with permutations of with/without signal strength and with/without top line. They would be placed into android device mock, shrunk and cropped to fit the 300x250 image size limit. I'm debating running this question format as an image with open ended "what would you tap on" and or image with pick-1 menu listing the various text targets.

Great! helenharris@ is super duper helpful with GCS. You can book office hours with Chrome UXRs at go/chrome-uxr-oh (Tuesday mornings or Wednesday afternoons.) Also feel free to email and cc me. I can help make images too, once you've landed on a question format. (Because of size constraints we might have to approximate the problem.)

Removing myself and adding cleer@ as primary design contact for interaction (hannahs can weigh in on visuals if needed too)

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot