Cue artifact 1:
 |
| 1a |
So here we have the icons for visibility and muting swapped. I don't know about you, but those eyes look quite creepy (or downright wrong) hanging out over on the left. But at least now we know that curve visibility is denoted by the eye, and muting status (whether curve is used when being evaluated) is represented by the checkmark.
An implication of the above is that the NLA Editor channel list now starts looking like:
 |
| 1b |
---
Ok, now let us suppose for a moment that we should keep using these icons as presented in 1a. What could we do about not having the eye on the left (supposing that is not something we want)?
2) Instead of just swapping the icons and keeping the functions in the same place, how about we swap both. So the list now looks like it's familiar state:
 |
| 2 |
At first this looks like it might be workable, but then we see a few problems:
- in all other options, visibility of the curve is tied to the box showing the color of the F-Curve, whereas here, color ends up being tied up to evaluation status (display vs eval mismatch here)
- potential for confusion
- Action Editor doesn't have visibility toggles, but does have the muting ones. This situation here would introduce an inconsistency between Action Editor and Graph Editor in terms of what's displayed on the RHS. This really puts the final nail in this coffin.
---
3) Perhaps if we tried putting all the toggles on the right, then all our problems would be solved?
Well, not really :/
The main sticking point here is what we do with the colour indicator.
- If we leave it on the left, then do we put something in it, or leave it blank. Leaving it blank will feel like a wastage of space. Putting an array index in there might not be the wisest of moves (I've seen mockups of this, but I can imagine it getting a bit shaggy if you've got some location transforms with text starting from the square juxtaposed against subsurf-levels or some other single property where the text would need to start after the square).
- Moving it to the right, and putting it under the visibility toggle wouldn't really work that well either. While it is now still associated with that toggle, it now looks weird and breaks the left-to-right scanning correspondence between colours and the names of the F-Curves they represent. At the end of the day, most users are English speakers, who are used to left to right reading, where it just looks more natural to have a bullet point followed by the content associated with it, instead of having it floating around the other end.
- We could alternatively put the colour indicator under the whole entry, although I can say I've been-there-done-that very very early on (I've still got screenshot evidence if you're curious), and it's safe to say that was a disaster. The text really didn't read that well when I did that.
---
So, at the end of the day, perhaps we'll have to settle for 1a (unless somebody comes up with a brilliant 4!), though it does still look incredibly odd IMO. As for the NLA in 1b, thoughts?
One thing that might help readability/clutter here is to remove the names of the id blocks from the name of the fcurve - you can see this above where it says (world), (world), (world), and (cube), (cube), (cube).
ReplyDeleteThis is pretty useless information since you can see what the object is right about it. Perhaps if it's a situation where fcurves are coming from multiple bits of data (or non-ID data, like the subsurf) it might be handy but in most cases it's not, and just adds to the visual mess. It might be good to try removing this text in those cases (and/or putting it in a tooltip).
While you're at it, I'd suggest taking a look at the naming in the NLA editor too - I think you could easily get rid of those superflous 'ActAction' bits and the < > as well. Those actions are easily identified by the action icon and line colour, and don't need that text. This would also make it much easier to scan-read: in left-to-right languages people generally scan through lists of text with the eye scanning down the left edge of the list.
cheers
Looking at Gimp's layer dialogue the checkable icons are on the left- not saying this is better, but more standard. Considering Photoshop has layer groups, Gimp 2.7 may? it may be a good place to look as well. Glad to see the eye will represent visibility finally!
ReplyDeleteI like option 2 :)
ReplyDeleteYou know a mute icon in most music programs (and almost everything else) is a speaker with a strikethrough. I wonder if that would be better than a tick, so we would have 3 icons that make visual sense, an eye for visible, a speaker for mute and a lock for lock.
ReplyDelete~Glenn
Matt: Thanks. Taken into account and committed tweaks :)
ReplyDeleteGlenn: I've been thinking over that option too. It's just a bit more work (doing pixel-art and dealing with some difficult to merge files - i.e. icon file).
Here's what i thought would be simpler. For visibility, remove the checkbox, and let user decide which one is visible by simply selecting it. they can use 'a' shortcut for viewing all, ctrl+click for multiple selection, using 'b' shortcut for blocking it, and just deselect it to hide it.. So we don't have to select it, and then press 'v' to make it visible anymore. it's just too much clicking at the moment.
ReplyDeletefor mute and lock button, i like it just the way it is right now :)
Nice one, that was quick!
ReplyDeletePersonally I found 2 to be the most intuitive. Even if the colour box can't be underneath the eye.
ReplyDeleteAs for the NLA, I'm with Matt in that those ActAction bits can be removed. I understand they're used to show the non-NLA data, but can't that be pushed up to the same level as the Object itself?
Hi!
ReplyDeleteThanks for all the great improvements done to the Blender animation system.
I have a small feature request that would really help in some situations:
When a scene has hundreds of keyframes, it is often better to work in dopesheet since the overview there is less cluttered.
What would be really awesome would be the ability to edit the keyframe values directly in the dopesheet, simply by clicking on a keyframe. If someone uses After Effects, then you might know how clicking on a keyframe brings up a small dialogue box displaying its value and you can edit the value in that same box.
At the moment I have about 50 animated lamps in my scene and I realize that I need to change the end keyframe value of them all to be brighter. Currently I have to position the playhead on the exact keyframe location in order to edit it (without going to graph editor) and this is a major PITA. It would be so nice if I could just double-click on a keyframe to change its value regardles of my current playhead position.
Antti: turn on the "Show Sliders" option
ReplyDelete