GNOME Bugzilla – Bug 676912
lock icon/button breaks a decade of established visual idiom
Last modified: 2018-05-02 15:26:07 UTC
Created attachment 215087 [details] Real world example of use of lock idiom. The lock icon in the User Accounts control used to lock and unlock the control is the converse of the established idiom. That is the closed lock icon indicated an imperative verb to close the control (i.e. the control is *not* locked), where for the past decade or so in the GUI domain a closed lock icon (example the status bar in web browsers) has indicated the state noun that the control *is* locked. The established idiom reflects the real world, where a closed lock indicates... a closed lock, and in other graphical representations of locking status for non-padlock type objects (for example the file attached). Given that representation of verbs is difficult in graphic idioms without movement and particularly with small icons I would suggest that the the icon button set be changed from a closed lock in the button to indicate "lock the control" and an open lock in the button to indicate "unlock the control", to the more established graphic of a closed lock *next to* the button to indicate "locked" and an open lock *next to* the button to indicate "unlocked".
(In reply to comment #0) ... > That is the closed lock icon indicated an imperative verb to close the control > (i.e. the control is *not* locked), ... Um, that's what we do, isn't it? The button has the locked icon and 'lock' when the panel is unlocked, and vice versa. The label refers to the action when the button is pressed, rather than the current state (ie. 'lock' is a verb in this case.)
You are correct, that is exactly what you do, and I am claiming that that is not the idiomatic way to communicate here. The lock icon should be be a state noun - just as a locked lock indicates a state of lockedness, whereas an unlocked lock indicates a state of unlockedness. Sorry, but I thought it was pretty clear that that was what I was saying in the report.
(In reply to comment #2) > You are correct, that is exactly what you do, and I am claiming that that is > not the idiomatic way to communicate here. The lock icon should be be a state > noun - just as a locked lock indicates a state of lockedness, whereas an > unlocked lock indicates a state of unlockedness. Ah right. Not sure I agree here. The button label indicates what happens when you click on the button. This is very much the convention - 'Close', 'Open', 'Launch Nukes', etc. If we labelled the button with the current state, the button action wouldn't be clear.
You are right, it would be confusing to have the orientation I'm suggesting with the lock in the button, which is why I suggested that that lock not be in the button, but rather next to it. If you must have the lock in the button, you absolutely need to improve the visual representation of the fact that it represents a verb, because at the moment you are mixing metaphors.
Here is an (admittedly ugly) example of what I see as the correct idiom http://community.pepperdine.edu/it/images/security/fire-pers-mac-10.jpg / http://www.usc.edu/its/private/images/mac_os_x/osx5_uscnetwork.jpg ... and no, I'm not a mac user.
We did use that style before we switched to the one we are using now.
OK. Then I'd consider it a regression.
I agree with Kortschak on this. The established behaviour for a toggle in the current implementation of gnome is to display the current state of the toggle (i.e. the switch metaphor). With the switch control, it visually shows the state the toggle is in, and it is implied that when you press a switch that is "On", the user knows that the result will be off. This should be the same for the lock / unlock. It should display the current state the toggle is in, and the user knows that when they press it, it will unlock. For a real-life analogy, the best example of this would be a bathroom stall, with an "Engaged / Vacant" lock. It does not display the action, it displays the current state of the toggle.
Reassigning to GTK+, as that's where the lock button lives now.
*** Bug 702768 has been marked as a duplicate of this bug. ***
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
OK. Unless this has been fixed - which seems unlikely since there seems to have been little interest in fixing it and a significant level of push-back. Then I would like it reopened, but I don't see how other than commenting here.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/396.