Bug 365254 - Usability: Removing Buttons from the window decoration is confusing
Summary: Usability: Removing Buttons from the window decoration is confusing
Status: RESOLVED FIXED
Alias: None
Product: kwin
Classification: Plasma
Component: decorations (show other bugs)
Version: 5.13.1
Platform: Neon Linux
: NOR minor
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-07-08 20:40 UTC by Alex
Modified: 2019-04-30 18:36 UTC (History)
5 users (show)

See Also:
Latest Commit:
Version Fixed In: 5.15.0
Sentry Crash Report:
kainz.a: Usability+


Attachments
Screenshot of the Dialog using a themes Minus sign (16.36 KB, image/png)
2018-07-18 18:45 UTC, Alex
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Alex 2016-07-08 20:40:57 UTC
When configuring the buttons for the window decoration, the area with the available buttons turns into a forbidden sign, when dragging buttons from the title bar in the direction of this area.

If there wasn't the text "drag here to remove button", i would have guessed, it would tell me that i CANNOT drag the button there.

Does it even need this hint? Maybe there should be a static hint at bottom "drag from the titlebar here to remove buttons from the titlebar", but the current look conveys the wrong association.

Reproducible: Always
Comment 1 Martin Flöser 2016-07-11 06:53:21 UTC
That's not a forbidden icon, but list-remove. If that's unsuited we might find a better fitting one.
Comment 2 andreas 2016-07-11 07:45:50 UTC
In general I think it's the right icon cause you remove something from the titlebar.

I'm not sure if you need the dialgue, cause you write on bottom
Drag buttons between here and the titlebar
so it should be clear that you can drag some icons to the titlebar and remove them. I would remove the dialogue, cause you remove something but it's easy to move it back to the title bar.
Comment 3 Thomas Lübking 2016-07-11 08:16:13 UTC
lower the opacity over the drop zone?
Comment 4 Alex 2016-07-11 15:40:54 UTC
I didn't want to say it's the wrong icon by some definition in a icon scheme, but that experience the UX here as confusing. Its not the icon, which is the problem, but the workflow.

I would think moving between two areas (title bar and icon-area) has the right intuition without any further hints (as you are actually moving the icon back and forth, without removing (in the sense of deleting) it).
Some mouseover effects may be useful, but i would consider this one as not the best one to convey what's happening.

Just as a minor UX issue, no priority here.
Comment 5 Thomas Pfeiffer 2016-07-11 16:47:40 UTC
I think it is wrong. Breeze using the wrong metaphor for "remove" in general. That sign is indeed a "forbidden" sign, not a "remove" sign.
I don't think we need any icon there. If you move a button from the window decoration to the pool of available buttons, it's clear that you remove it from the title bar. No further indication needed.

So yes, please remove that misleading icon.
Comment 6 Alex 2018-07-18 18:45:29 UTC
Created attachment 114004 [details]
Screenshot of the Dialog using a themes Minus sign
Comment 7 Alex 2018-07-18 18:49:58 UTC
The icon is now replaced by a minus sign, which is indeed a better choice.
But at least in my plastik theme it still looks confusing. First I thought if it should display some ruby or similar.

But do we need a sign there at all? Mozilla Firefox uses the same metaphor of a "unused icons" place and drag&drop and it works without additional indicators.

In particular, the metaphor with a remove-icon seems wrong to me as I do not remove (in the metaphor: remove from both the title bar and the icon pool) the icon, but just *move* it to the unused icons below.
I think it was like this in KDE 4 and maybe some 5 versions, I do not know the decision process why it was changed so I hope I did not overlook something.
Comment 8 Björn Feber 2019-04-27 13:57:06 UTC
Yeah, I think we can remove that inidcator.
Comment 9 Nate Graham 2019-04-29 03:36:00 UTC
The icon has text that explains it, and now it uses an emblem icon so the meaning is a bit clearer. So I think the original issue is effectively resolved

We could still remove the icon of course, but I don't think that's necessary from the perspective of calling this issue fixed.
Comment 10 Thomas Pfeiffer 2019-04-30 18:36:11 UTC
I have created a wishlist item to remove the icon ( BUG 407109 )