UI: Updated Auto Keying Button Icon #105574
No reviewers
Pablo Vazquez
Labels
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
12 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#105574
Loading…
Reference in New Issue
No description provided.
Delete Branch "Harley/blender:RecordRed"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Changing the icons used for auto keying to be more noticeable.
This patch replaces the icon used by the auto-keying button with a pair for off and on. The "on" version being a bit larger than we have now, and the "off" state uses an unfilled circle because that indicates a better "off" and has greater luminance change.
I like "red" is record, that is kind of a universal "recording is going on" indicator.
The only change would be to keep the white outline so you don't change size just red fill.
I do too. But there is a chance that the perception of it could differ by age with older people seeing it as normal because of audio and video recorders, while younger people could just see it as an "error" color.
Some red-green colorblindness could also alter this perception. Usually for them we push the color toward yellow into orange. Which could make sense for all since that is more of a warning color. Or maybe a bright orange-yellow?
The icons are created and stored as monochrome, just shades of white. But we are able to recolor these at will, so showing them as white on the dark theme while black on the light theme. So we can make it any color as long as it is one hue, not multiple at a time.
The change of size though is because I am just using our "radio button off" icon here, which isn't quite the right size. If this is something we like then we'd have to create a new icon in the set specifically for "record off"
Audacity also has a 'red dot' recording button, and so does Reaper. These are always red, though, and not just when they are enabled.
I think either of these would work:
In both cases the red colour is not the only thing that conveys the information, so it should be fine for colourblind people.
That's a shame.
👍
24514f2d5eto73aab156d3My comment about that was a bit wrong-ish. All our current icons are white so that we can re-color them for display. So we can turn that white source icon into one that is black or blue or green.
But... it works just fine if the source icon image has colors, even multiple colors or gradients, etc. Just doing so would not allow us to recolor it later. Of course that does not matter in this case. So the icons in this PR have both a white ring and a red interior. And it looks just fine in both dark and light themes.
@blender-bot package
Package build started. Download here when ready.
Currently (not in PR yet) have a "disabled" state here that I quite like:
My worry with it being that grey/faded it looks like it can't be clicked vs. off, if you have the white circle the same brightness as the play buttons, full white then it doesn't look disabled/unclickable maybe.
Because if you compare the drop down arrow next to it, it is the same light grey and it is disabled... unclickable.
well.. clicked the wrong comment
Good point. I'll keep playing.
77480c4ee3to0772dda353Some users will have a tough time with the red indication and blue background. So I updated the the icons to use only a single color, but you can set the color in the theme. That way anyone who hates the red can set it to white or yellow or anything else. I updated the original comment and the images there.
we coukd maybe consider it as the other play forward, play backward, pause buttons.
they don't have a pressed blue state.in that case we can use the white circle for disabled autokey, and white circle and red fill for auto key on.
edit:
i was wrong, they have pressed blue state. What i was looking at is the play button which changes from play to pause but doesn't stay in pressed blue state.
I updated the animated gif capture in the first comment. Now using icons that exactly match the design language of other icons that have an on and off state:
I like the button in your last comment 👍
I guess this wasn't finalized in any of the meetings, what is left to do?
I think the last version is pretty nice (in the first comment), and allows users or theme designers to change the color if needed.
The next step should really be your module deciding if this is wanted or not. If yes I can then see what UI module thinks.
Yes having has this just mess me up once again when working, I really do want to see with a quick glance at the UI that I am in "record" mode with auto key on.
I'm in favor of this.
Also, the auto-key button was already red pre-2.80:
So in some ways this is just going back to how it was originally supposed to be. (Although it was always red, not just when toggled on.)
I suspect the reason it was changed in 2.80 was to make the UI stylistically consistent. But I think this is a clear case where clarity trumps style. Moreover, this patch still IMO keeps things stylistically consistent while in some ways being even more clear than pre-2.80, by making the button only colored when auto-key is turned on.
This was discussed in this week's Animation & Rigging module meeting. The outcomes:
7b115721c5toa4538f308bWIP: Evaluate Red Auto Keying Buttonto UI: Red Auto Keying Button@pablovazquez - This change is wanted by the Animation and Rigging module. Can you see any problems with doing so? Pre-2.8 did have a red "record" button and it was part of the plan post 2.8 to do so as well but never got done.
The red color could be too strong and distracting, at least the shade of it in the example that was shown
The current implementation with blue color is simple and elegant for my taste.
@Rockbard it should be strong and very visible as it is both a warning that it is on and a universal "recording" color that lets you know you are going to set keys.
Just an idea, how about we bring the classic camera recording sign which is blinking red dot when turned on? I think it will be more obvious to identify than Auto-keyframe status message.
@Harley could you please update this patch? The first gif shows the icon in one way and in the second image looks larger. Not sure which one is the latest. Thanks!
a4538f308bto90badb06f3No problem. I updated the patch and replaced both images in the first comment.
I think that would be very obvious indeed, but also rather annoying to any animator who has auto-keying turned on permanently.
Well if you going to use red, I suggest taking this shade of red from the sidebar icons to maintain the color scheme cohesiveness.
I think that looks quite bad to be honest, although I struggle with finding any red that looks good with our default blue highlight color.
The best thing is to run the PR and change the color in Themes / User Interface / Icon Colors to something that you like. Then paste a capture of the resulting record button here. Or - even easier - just take the image below and mock it up with a color you like and paste it back here.
Here are a few variations. The one on left is how it looks by default in the PR. Next is from the Properties categories, then a couple from the 3DView Cursor tool, then one taken from the 3D navigation gizmo.
Yeah, you are right actually, thats because the brightness value is quite similar to the bg color.
The color should stand out either by value or by saturation.
But still not to stand out too much from the overall scheme I think.
The one on the left (the original) is the only one that doesn't hurt to look at. It's the best option for sure IMO
"Hurt to look at" is hard to really say without seeing it in the full interface at the correct size, isolated images are misleading and don't show the context of the change.
A full screen capture of it in the UI for size and color is best.
Here's a capture of the entire interface with defaults and at 1X scale, with that option turned on:
I'm not an animator but I get the impression that having the red dot being dark brown is not matching the association of a glowing record signal anyway.
Any of the bright orange-red examples seems to fit Blenders UI the most and still read as a record button. But the bad color blindness accessiblity is unfortunate.
Seems to be a choice between favoring accessibility or color association. Or leaving it as is for the best contrast?
Yep, the struggle is real :) Here is another take.
For vision accessibility for colorblindness what we are trying to avoid is requiring a differentiation of red and green, or between other colors for less common variations. The colorblind see colors, but have difficulty differentiating between some, for example red and green might look the same.
So the colorblind will see this as an off to on change, but they might see the red color differently than us. And here we have the added change in that the off state is an unfilled circle, where today the internal dot is the same color and brightness whether on or off. So this should be an improvement even for the rare monochromatism.
And if we continue to find all shades of red ugly with our blue, an option is to do only the icon change. Therefore have an on/off cycle like this, which is still some improvement.
Color blind person here! That's certainly one of the considerations. Another consideration is luminance perception. For example, reds appear much darker to me than to people with normal color vision. As an example:
That red is so dark to me that at-a-glance it is difficult to distinguish from the dark grays in the rest of Blender's UI. The surrounding blue notwithstanding, it would look disabled to me.
Digression: it's also not quite right to say that I can't distinguish reds and greens, despite my color blindness being the red/green type. For example, with the except of the first on the left, in this image they're all more-or-less obviously shades of red to me:
"Red/green color blindness" is a misnomer, because color vision and color blindness isn't as simple as that. I actually have a harder time distinguishing equal blue-green mixes from gray, for example.
Anyway, digressions aside...
I'm not actually too worried here. Hopefully this won't offend other colorblind people, but as long as there is some clear visual distinction, I'm used to making do. I would prefer avoiding the (to me) very dark red option, but even then I can make do with the blue background as a distinguishing factor.
I still think that with the current ui theme the red circle is not fitting in the general interface design. I personally find it really disturbing expecially in combination with the blue highlight background.
My suggestion is once again to make it work with general contrast. Exclude hue and saturation form the context and watch the button only in luminance difference. In this situation rgb 1.0.0 equals 0.0.1 and 0.1.0.
This also makes clear why imo the current interfaces always work since white is always at higher values than any other rgb option as long as you choose at maximum 2 over 3 channels.
Anyway seems to me that this change, even if largely debated, still stays controversial in its application. So until something very new pops up on the table, i feel like we are turning in rounds here.
This seems to me the best option amongst the other:
#105574 (comment)
Yes, I think the best (or the only good) part of this PR is the change of the off-state icon to an unfilled circle. And that the on-state filled circle is a larger than now. Currently there just is no change in the icon between states.
That is accepting this PR except with the change of the default color of the icon to white. That way by default it would look like that but users (and theme designers) could choose otherwise.
just a coincidence but I was trying to have something like that when autokey is on :
A small button color change is not enough for me at least and autokey , or the lack of visual clue make me lose so much time per projects ... just my 2 cents. It can be ignored :D
@Harley
In that case, I propose that we land this with just those changes, since they're an obvious and (I think?) uncontroversial improvement. And then deciding on whether we also want a color change, and what that color should be, can be discussed separately. That way we at least get the obvious improvement now, rather than risking never getting any improvement because color is hard.
c58f7744ceto9bc54cf0b5UI: Red Auto Keying Buttonto UI: Updated Auto Keying Button Icon