Maniphest T76387

No "Add driver" context menu item for already keyframed property (bad UX)
Closed, Archived

Assigned To
Ankit Meel (ankitm)
Authored By
Eneko Castresana Vara (ecv)
May 4 2020, 4:14 AM
Tags
  • BF Blender
Subscribers
Ankit Meel (ankitm)
Eneko Castresana Vara (ecv)

Description

System Information
Operating system: Ubuntu 18.04.4 LTS
Graphics card: GeForce GTX 950M

Blender Version
Broken: 2.79b - 2.82.7
Worked: ?

The title says it all.

Why is this bad UX? It made me waste about 5h. Read my case, please: Please understand that not all users use Blender regularly, I for instance use it for months at a time, yes, but sparingly. I had made this model over a year ago, two bones' transforms' properties of which I had attached drivers to. Today I appended this model to a new blend. I forgot to append as well the python script used in the drivers so I did it after, ran it... but the drivers didn't work yet. So then I tried to re-attach the drivers... but to my surprise I couldn't find the "Add driver" menu item in the context menu. For the last 5 hours I have been searching all over the net specifically how to add drivers to bones, watching video tutorials, asking in online chats. Until I almost miraculously found an answer on SO stating the fact that drivers can not be assigned to already keyframed properties (unless through shortcut). Apparently I had keyframed the driven properties along with others when animating my model over a year ago. The price of this "mistake" of mine has been 5 hours gone to waste. I insist, not all of us use Blender every day. This is bad UX. I found a resolved issue about crashing when adding a driver to an already keyframed property, and I'm not sure if the commit fixed the crash or worked around it, but at the very least one would expect the menu item to be there and then if it's problematic get some info popup stating the issue, or at the very least something in stdout or whatnot!

I wouldn't like other "poor souls" like me to go through this. Please consider adding the menu item and (if relevant) informing the user they shouldn't do it. It's very confusing to know you added a driver there in the first place but somehow you can't do it anymore!

Thank you very much for your attention.

Event Timeline

Eneko Castresana Vara (ecv) created this task.May 4 2020, 4:14 AM
Ankit Meel (ankitm) changed the task status from Needs Triage to Needs Information from User.EditedMay 4 2020, 8:54 AM
Ankit Meel (ankitm) added a subscriber: Ankit Meel (ankitm).

Removed as per author's request.

Ankit Meel (ankitm) closed this task as Archived.EditedMay 12 2020, 1:44 PM
Ankit Meel (ankitm) claimed this task.

Removed as per author's request.

Eneko Castresana Vara (ecv) added a comment.May 17 2020, 2:58 AM

Hi, @Ankit Meel (ankitm) . While I understand it is easier to work with and thus desirable to get schematic soulless reports, I happen to be a human being with my own variance of emotional charge on different situations, which do not always nor consistently allow for such a desirable curation irrespective of whether I KNOW how to make it happen, which I do. This is to say, as a person, I have only SO MUCH control (regardless of personal responsibility) on my behavior over matters from which I personally infer a high emotional charge. I'm sure this is the case for everyone else at different degrees, just as I'm sure shame or BESHAMING would be a major deterrent to others whereas to others like me it would be a major driver of belligerence. So in retrospect, and for my own sake, and foreseeing a reply such as yours may happen, I'm glad I took the time I needed to cool down before checking back on this anymore, as otherwise my response would have been a lot less curated than the current one and more unnecessary suffering (at least for myself) would have ensued.

  1. Assuming closure as a feature request

It is at the very least, bemusing and ironic (not wanting to turn to name calling here), to meet such assumption coming from who's calling for a more curated input, considering the latter precisely involves filtering out irrelevant personal charge, and assumptions are, if anything, personal, except for generalized biases based on belief which are generally considered to be true for a lack of facts. Also shall I opine, “Before this is closed as feature request” feels arrogant at best.

  1. Why this is not a feature request but a bug

For a lack of a better reference from a more relevant authority, the second and relevant acceptation of the first entry for the Merriam-Webster online dictionary on "bug" says the following:
"An unexpected defect, fault, flaw, or imperfection".
One would generally expect to be able to add back a driver deleted before by oneself in the first place. It doesn't get any simpler than this. It is an unexpected event not to be able to, and I would consider it a defect and therefore a bug.
As for a relevant definition of "feature" one could refer to https://en.wikipedia.org/wiki/Software_feature where they cite the definition in IEEE 829 of Software test documentation: "A distinguishing characteristic of a software item (e.g., performance, portability, or functionality).". I wouldn't consider fixing a problem, of programmatic nature or not, a feature of any kind, regardless of whether it involves UI modifications or additions. I'm not sure if Blender bug triage is driven by the rationale of considering anything not being purely of programmatic nature as features tho.

  1. Making my case on my report

Being stuck for about 5 hours talks so much about being non-knowledgeable about this specificity at the moment, as it talks about this particular implementation not resulting intuitive enough. If only, because of this implementation not resulting intuitive enough, and because I could add drivers to other elements, it is that I incorrectly assumed that bones’ transforms may not use drivers, which is a very logical assumption for a lack of more knowledge. Given I deem myself obsessively goal-oriented, and because generally we people focus on one thing at a time, and hardly have any sort of parallel conscious thought processes, it is no wonder I was stuck with the problem for that long. All this goes to say, despite being fully responsible for this outcome due to my free choice of the software, the bug is real, and assuming the problem is solely one of personal responsibility over the software knowledge is bogus.

  1. "Rant"

"Regardless, rant isn't way to describe an issue."
These are, again like the aforementioned assumptions, personal appraisals, which don't speak well on behalf of the consistency of your request (note I'm assuming here your suggestion was an actual request as per the follow-up closure message) for an implicitly depersonalized version: Determining whether my report is a rant or not depends on each individual's judgment (since objectively confrontational emotional inflections can hardly be inferred from it), as is believing (or liking) whether it is or it is not a (proper) way of describing an issue. As the author, I am the only one really equipped to determine whether it is a rant or not, and on this regard I'm not entirely sure it is, but what I can say is: despite being emotionally heightened (and reasonably so) when it was written, I strove to be both as relevant and comprehensive as I could possibly be. If according to you, I failed, that's where it ends. NO NEED TO TALK DOWN.
As a 40 year old person with a real full name here, I most certainly DO NOT appreciate nor welcome being TALKED DOWN by a stranger without one (I guess that makes things easier, doesn't it?). I reckon this is hardly a place to instruct in the first place a stranger on matters of adequacy on general procedures or methodologies.
Also, and anticipating this is, indeed, my personal appraisal, I have to say that "But even after that, it's not guaranteed that it'll not be closed." feels a tad authoritarian, because if I played your role, I'd find hardly a reason to state the obvious (that it might be closed regardless) unless I was trying to warn not to bother to reshape it because it will most likely be closed anyways, because I'd have allegedly already formed prejudice based on the original report to the effect of closing it regardless.

  1. "Lacking" information and guidelines

"This report does not contain all the requested information, which is required for us to investigate the issue."
All the necessary information about the issue to investigate it is right there within the report. It certainly isn't in a depersonalized nor schematic form as implicitly and unmannerly requested, but it is right there.
Also, as informative as the guidelines may be, it is possible referring me to them isn't entirely appropriate for two reasons:

  1. The aforementioned personal struggle of control over "knows". That is to say, do not assume all my actions and behaviors are solely driven by knowledge or its lack thereof.
  2. A click on my username reveals and supports the notion that the knowledge on the how, is there already, as despite not being a big contributor in bug reporting, I have undoubtedly done this in the past quite successfully.

Now, if this is a canned reply, it seems unfortunately unfit for this case.

Lastly, I have no restraint on taking this to the next level, if such is your will and kindly provide your full name, and make a legal case out of it, as in my country, Spain, HONOR is a right, and affronts to it may be considered crimes, and it seems plausible to make a case, as publicly talking down on someone falsely implying they lack adequacy, looks like a good candidate.

Otherwise, and as per your example, I suggest you edit out all the implicitly and falsely accusatory offending parts, or, to be safe, all of your first reply, in which case I will mercifully delete this very same reply, and let the issue sink down the bottom of my mind, even though I unfortunately (for me) never forget affronts and relive them quite often.

In case it isn't obvious by now, I won't be editing my report, as a matter of pride (function can never supersede motives), and at this point, I couldn't care less if the reported issue is ever resolved or not. But I am also taking screenshots and HTML copies of the present page, and uploading them right after to Google Drive as a proof of no-tampering, should this page be completely erased (which WILL NOT reinstate me, as simply silently erasing it as a whole doesn’t repay me for the image damage already caused, whereas CORRECTING or erasing the unmannered and implicitly defamatory reply does. I thought I would state the obvious here just in case) and thus should I need to further my case legally.

Ankit Meel (ankitm) added a comment.May 17 2020, 9:19 AM

I'm glad I took the time I needed to cool down before checking back on this anymore,

Thank you! I'm sorry if my comments came out as rude, or added to your frustration.

I'm not sure if Blender bug triage is driven by the rationale of considering anything not being purely of programmatic nature as features tho.

https://wiki.blender.org/wiki/Reference/Not_a_bug

because of this implementation not resulting intuitive enough,

I'm not saying that current way is the best way, or that it shouldn't be changed. That is for module owners to decide. And I'm sure they'd appreciate an explanation, an alternative, and not having to sift through a report full of frustration. I, while triaging try to edit reports which are not properly explained, or don't have a blend file to redo the bug, so that the person who's fixing it doesn't have to bear it.
Here, I am not familiar with the problem, so I asked you to improve it.

If according to you, I failed, that's where it ends. NO NEED TO TALK DOWN.

Commenting on about 20-25 reports per day, it seems I went straightforward there.

I guess that makes things easier, doesn't it?

In some corners of this website, I too have all my personal info written, all public. So certainly not.

unless I was trying to warn not to bother to reshape it because it will most likely be closed anyways,

That comes by experience. See this report for example: T76367: Sculpt mode: layer brush height info circle is too distracting.
It could happen that you put a lot of efforts, add screenshots, or mockups. But maybe that would fit on a design task which will be created later some time, not now. It is a bug fix sprint, as described at the end of https://code.blender.org/2020/05/tracker-curfew-wrap-up/. So design discussions could be happening in next release cycle. So it was very much possible, that if solving this issue requires a major work, or doesnt fit with current plan, it could be closed.
Also, when the report is clear about what is required, a triager would confirm it, a developer will look at it & decide if it should be marked as "todo" or not. If it's not a major code change, it is possible that it is fixed right away.
So I was not arrogant, or authoritarian in saying that it could be closed as feature request too, just honest.

Now, if this is a canned reply, it seems unfortunately unfit for this case.

yes it was. It should have been "no reply for over 7 days" which tracker policy says should be closed.

A click on my username reveals and supports the notion that the knowledge on the how, is there already, as despite not being a big contributor in bug reporting, I have undoubtedly done this in the past quite successfully.

I just checked that, and yes, you're correct. Thank you for helping to improve Blender.

I suggest you edit out ... all of your first reply..

Done.


It would be very nice, if you could make a new task, and link this task there, if you'd like.
All this editing comments, closing, reopening simply doesn't help with the cause.