Use visible buttons to switch the default device
ClosedPublic

Authored by ngraham on Aug 24 2019, 2:31 AM.

Details

Summary

We get numerous complaints that it's hard to figure out how to make an audio device the
default for playback or output. Despite the multiple methods (drag-and-drop, hamburger
menu item, radio button in the KCM), it still seems un-discoverable for many users.

This patch attempts to address the issue by standardizing on a single consistent method:
Make default buttons right there on the list items for the devices, for both the applet
and the KCM.The buttons are only shown when there is more than one device that could
be the default.

Various other elements of the UI are slightly adjusted or adapted to accommodate this change.

FEATURE: 411065
BUG: 408490
FIXED-IN: 5.17.0

Test Plan

Connected my Bluetooth speaker and toggled between it and the internal speakers using
the new button.

Applet:


KCM:

My wife was impressed by how easy it was and how the audio instantly switched.

Diff Detail

Repository
R115 Plasma Audio Volume Applet
Branch
master
Lint
No Linters Available
Unit
No Unit Test Coverage
Build Status
Buildable 15580
Build 15598: arc lint + arc unit
There are a very large number of changes, so older changes are hidden. Show Older Changes
ndavis added a subscriber: ndavis.EditedAug 24 2019, 10:50 AM

Why not it's a checkbox ? Make default looks big.

You can only have 1 default, but there are multiple devices, so the check box would have to be a radio button instead. However, a radio button would look strange in a list like that. You'd still need a label to show what the radio button does, so you'd be better off with a button.

ndavis added inline comments.Aug 24 2019, 10:57 AM
applet/contents/ui/ListItemBase.qml
120

According to the HIG, this should have title style capitalization.
https://hig.kde.org/style/writing/capitalization.html

ngraham updated this revision to Diff 64478.Aug 24 2019, 12:52 PM
ngraham marked an inline comment as done.

Use Title Case for button text

FWIW we implemented the same UI in Discover to solve the same problem (people didn't know how to set/change the default backend when multiple were present) and since then, we haven't had any user complaints at all.

But in settings is radio button

Should be changed there too; that's an inappropriate use of radio buttons. One doesn't even have a label so you have no idea what it does.

ngraham updated this revision to Diff 64489.Aug 24 2019, 4:10 PM

Do the same thing for the KCM

ngraham retitled this revision from [Applet] Move "Make default" action out of the context menu and into a discoverable button to Use "Make default" buttons to switch the default device.Aug 24 2019, 4:12 PM
ngraham edited the summary of this revision. (Show Details)
ngraham edited the test plan for this revision. (Show Details)
ngraham updated this revision to Diff 64490.Aug 24 2019, 4:17 PM

Make one more ToolButton into a button, just like in the Applet

ngraham edited the summary of this revision. (Show Details)Aug 24 2019, 4:18 PM
ngraham edited the test plan for this revision. (Show Details)

My big concern is that translated text is mainly not too big in English but in other lang. Even we change it to "Default Out" (since it has a label "Outputs").

Not a fan of icon only buttons for uncommon tasks, but if saving space ever becomes absolutely necessary, we could use the star icon for "Make Default" instead of having text.

I'm also not a fan of icons-only buttons, because their meaning is ambiguous unless the icon is perfect. And we don't have a perfect icon here. We could try moving the button down to the next row:

Even then, in Russian (from Google Translate at least), the text is quite long:

I can add a note for translators that this string should be kept as short as possible.

Would moving the button to the second row work better? What do people think?

I can add a note for translators that this string should be kept as short as possible.

Furthermore in bulgarian is even longer, there is no short word that fits "default" which can lead to stupid word cuts. What I can say, from my experience in other projects, you shouldn't add more than a word in button unless you want to became a fat, long, ugly, etc. That's way Android, many projects adds icons to every action to keep text out of the buttons.

I'm not using an icons-only button here. It wouldn't be clear; we need text. I understand with with certain languages, the text could be long. But without text there's no point to this feature, because it no longer solves the problem.

If the UI becomes too crammed as a result, we could consider resizing the pop-up.

ngraham updated this revision to Diff 64506.Aug 24 2019, 6:21 PM

Move button to second row where it won't be so obtrusive for languages where the text is really long

I'm also not a fan of icons-only buttons, because their meaning is ambiguous unless the icon is perfect. And we don't have a perfect icon here. We could try moving the button down to the next row:

Even then, in Russian (from Google Translate at least), the text is quite long:

I can add a note for translators that this string should be kept as short as possible.

Would moving the button to the second row work better? What do people think?

Even in English, I don't think that's a good button placement. The volume slider should definitely not be shortened. My headphones are usually only comfortable around 40% volume or less, so that significantly shortens the usable area of the slider. From the look of your settings, it looks like it's the same for you.

ngraham edited the test plan for this revision. (Show Details)Aug 24 2019, 6:22 PM

Well, we're at an impasse then.

  1. When the button is on the top row, if it's really long, it intrudes on and elides the device name
  2. When the button is on the bottom row, it shortens the volume slider
  3. If the button has no text, it's not clear what it does, and there's no real point to doing this in the first place

Does anyone have any alternative ideas, or should we live with 1 or 2?

alexde added a subscriber: alexde.Aug 24 2019, 6:26 PM

Just brainstorming: What about two sections, 1) "default" with a single entry and 2) "others".
The user could drag and drop the speaker to default place and the current default one would move downwards with an animation.

We already have a drag-and-drop UI for determining the default and nobody has ever figured it out. :) DnD is not very intuitive for things that don't look inherently draggable, or that people have become accustomed to dragging (like files and folders in a file manager).

alexde added a comment.EditedAug 24 2019, 6:31 PM

DnD is not very intuitive for things that don't look inherently draggable

That's why I draw a frame around the entries and also the mouse pointer could change to a hand. Otherwise I neither really like 1) or 2). How do other systems handle this?

Alternatively, what about the mockup I created plus a small button with an "arrow pointing upwards" and a hint if the mouse hovers over the button. Does that sound intuitive to you?

Maybe we should just keep the "Make Default" button in the hamburger menu? It's less visible, but we don't have much space and it's usually not as important as the device name and volume slider. We can keep the "Make Default" button in the audio KCM.

Maybe we should just keep the "Make Default" button in the hamburger menu? It's less visible, but we don't have much space and it's usually not as important as the device name and volume slider.

It's very important the moment you plug in a second device because we don't have "switch on connect" as the default behavior (for various technical reasons that are not yet fixable). Again, users aren't finding it in the hamburger menu.

ndavis added a comment.EditedAug 24 2019, 6:48 PM

Maybe we can add another line to the device item for the button to go on? Seems like it might just add visual bloat, but I can't actually think of a concrete reason why it would be bad. It could contain some small amount of useful info too, or maybe more controls from the hamburger menu.

for various technical reasons that are not yet fixable

Can you please point me to those? Is there ongoing work? I'm curious.

for various technical reasons that are not yet fixable

Can you please point me to those? Is there ongoing work? I'm curious.

Basically, we need to delete the Phonon KCM first, because the Phonon and PulseAudio KCMs each set conflicting PulseAudio modules. In order to have switch-on-connect be the default, plasma-pa needs to be in control, which means deleting the Phonon KCM. It's in progress. See T9091 and D22616. For background information that led to my understanding of this issue, see the discussion in https://bugs.kde.org/show_bug.cgi?id=392103 and https://bugs.kde.org/show_bug.cgi?id=392117.

Also, even after we do have the ability, I anticipate that doing switch-on-connect by default may be controversial, so it's not a done deal either.

Maybe we can add another line to the device item for the button to go on? Seems like it might just add visual bloat, but I can't actually think of a concrete reason why it would be bad. It could contain some small amount of useful info too, or maybe more controls from the hamburger menu.

Like this?

Maybe we can add another line to the device item for the button to go on? Seems like it might just add visual bloat, but I can't actually think of a concrete reason why it would be bad. It could contain some small amount of useful info too, or maybe more controls from the hamburger menu.

Like this?

Yes, although it feels a bit cramped. Does it have the correct margins?

No, the margins are messed up. I can fix them in this patch since it becomes more obvious.

ngraham updated this revision to Diff 64527.Aug 25 2019, 1:49 AM
  • Fix margins and alignment
  • Put the button on a new row in the applet
  • Use the button to also show which device is currently the default, rather than implying it
ngraham edited the summary of this revision. (Show Details)Aug 25 2019, 1:51 AM
ngraham edited the test plan for this revision. (Show Details)
ndavis added a comment.EditedAug 25 2019, 2:02 AM

I think this looks pretty good, but why are the bottom margins on the first item different from the second item?

Good question. Let me check it out.

shubham removed a subscriber: shubham.Aug 27 2019, 8:34 AM

Haven't had luck figuring out where this extra margin is coming from. given that it's already there, could we tackle that in a follow-up patch?

ndavis accepted this revision.Aug 28 2019, 6:51 PM

Haven't had luck figuring out where this extra margin is coming from. given that it's already there, could we tackle that in a follow-up patch?

Sure.

This revision is now accepted and ready to land.Aug 28 2019, 6:51 PM
GB_2 added a subscriber: GB_2.Aug 28 2019, 6:54 PM
GB_2 added inline comments.
applet/contents/ui/ListItemBase.qml
232

"Default Device"

233

What about always showing the icon?

ngraham updated this revision to Diff 64908.Aug 29 2019, 2:44 AM

Use Correct Capitalization

ngraham marked an inline comment as done.Aug 29 2019, 2:44 AM
ngraham added inline comments.
applet/contents/ui/ListItemBase.qml
233

I tried that, but it looked sort of weird. I kind of like how the presence of the icon helps to show what's the default device.

Here are some more UI possibilities I've been thinking of:

  • Instead of using pushbuttons, make them checkable toggle buttons, with the checked one being default
  • Go even farther and make the device icons into checkable buttons and badge the checked/default one with a little star icon in the corner to show that it's the default device.
ngraham edited the summary of this revision. (Show Details)Sep 3 2019, 4:45 PM
ndavis added a comment.Sep 3 2019, 5:48 PM

Here are some more UI possibilities I've been thinking of:

  • Instead of using pushbuttons, make them checkable toggle buttons, with the checked one being default

So the current version just disables the button on the default item? Toggleable buttons makes more sense.

  • Go even farther and make the device icons into checkable buttons and badge the checked/default one with a little star icon in the corner to show that it's the default device.

I'm torn on this one. On one hand, we lose the super obvious "make default" label. On the other hand, that would look pretty clean. Do you think people would recognize it or end up ignoring it?

So the current version just disables the button on the default item? Toggleable buttons makes more sense.

OK, will do.

  • Go even farther and make the device icons into checkable buttons and badge the checked/default one with a little star icon in the corner to show that it's the default device.

I'm torn on this one. On one hand, we lose the super obvious "make default" label. On the other hand, that would look pretty clean. Do you think people would recognize it or end up ignoring it?

I have the same worry, which is why I haven't done it.

ngraham updated this revision to Diff 65354.Sep 3 2019, 7:48 PM

Use checkable buttons

ngraham edited the test plan for this revision. (Show Details)Sep 3 2019, 7:50 PM
ngraham added a subscriber: broulik.Sep 3 2019, 7:52 PM

See the new FIXME: I can't figure out how to get the non-default device's button to become unchecked. It seems like the binding is broken. The non-default button disables itself flawlessly when I do enabled: !PulseObject.default, but does not become unchecked properly when I do checked: PulseObject.default

I could use a hand with this @broulik or anyone else in Plasma, if you have the time.

GB_2 added a comment.Sep 11 2019, 10:17 AM

See the new FIXME: I can't figure out how to get the non-default device's button to become unchecked. It seems like the binding is broken. The non-default button disables itself flawlessly when I do enabled: !PulseObject.default, but does not become unchecked properly when I do checked: PulseObject.default

I could use a hand with this @broulik or anyone else in Plasma, if you have the time.

I think a ButtonGroup could help: https://doc.qt.io/qt-5/qml-qtquick-controls2-buttongroup.html

GB_2 added inline comments.Sep 11 2019, 10:25 AM
applet/contents/ui/ListItemBase.qml
233

Maybe you can also use star-shape

ngraham updated this revision to Diff 65888.Sep 11 2019, 10:55 PM
ngraham marked an inline comment as done.
  • Fix it by using Button from PlasmaComponents3, which handles exclusive checkable state properly (it's impossible to do with PC2)
  • Use an outline-style star for the non-default item's button
ngraham edited the summary of this revision. (Show Details)Sep 11 2019, 10:57 PM
ngraham edited the test plan for this revision. (Show Details)
ndavis added a comment.EditedSep 11 2019, 11:46 PM

I find the use of filled and empty stars visually odd. They're like Jerry-rigged radio buttons that look like PushButtons. We also can't guarantee that star-shape will be empty and favorite will be filled in 3rd party icon themes. It's not at all obvious from the names of the icons that one should be filled and one should be empty either.

ndavis requested changes to this revision.Sep 11 2019, 11:54 PM
This revision now requires changes to proceed.Sep 11 2019, 11:54 PM
ngraham updated this revision to Diff 65891.Sep 12 2019, 12:10 AM

Used filled stars everywhere

ngraham updated this revision to Diff 65892.Sep 12 2019, 12:13 AM

Remove remaining FIXME because it's now fixed

ndavis accepted this revision.Sep 12 2019, 12:57 AM
This revision is now accepted and ready to land.Sep 12 2019, 12:57 AM

If possible I'd like target this for Plasma 5.17, which branches in 8 days, and I'd appreciate a review from @drosca or a Plasma person first.

ngraham retitled this revision from Use "Make default" buttons to switch the default device to Use visible buttons to switch the default device.Sep 12 2019, 2:31 AM

Since it seems that there are no formal objections or change requests, I will land this in time for the 5.17 beta.

This revision was automatically updated to reflect the committed changes.