Where to report UX issues?

Archive User Feedback
1

I have created following bug report:#105982 - Geometry Nodes Copy/Create inconsistency - blender - Blender Projects

It describes the the problem where this geometry nodes datablock selector:
image
behaves differently to this geometry nodes datablock selector:
image
Namely that this icon button:
image
does something very different than this icon button:
image
Can’t see the difference? Me neither!

The first datablock selector is from the modifier UI, and the copy icon button doesn’t actually copy existing datablock, but creates a new empty one using the bpy.ops.node.new_geometry_node_group_assign() command:
image

The second datablock selector is from the Geometry Nodes editor, and the copy icon button does actually copy the datablock using the bpy.ops.object.geometry_node_tree_copy_assign() command:
image

Let’s compare this to very analogous datablock type, a material. Material is also a node network, and like geometry nodes, material also has two datablock selectors, one in the material editor, and one in the properties panel. The datablock selector for material is also identical layout-wise to geometry nodes datablock selector.

In case of the material, both of these selectors run exactly the same command and behave exactly the same, making a copy of existing datablock (even though the description is incorrectly named):
image
image

So in the case Geometry Nodes, the very same button, with the very same icon, located at exactly the same place in the very same UI element compound does two different things. This is clearly a bug, so obviously, it was rejected from the bug tracker.

This is clearly not the type of feature request that belongs to right click select. That site is not designed to collect, aggregate and categorize minor UX fixes.

Where do we report these issues? In terms of impact on day to day workflow and usability, they are often significantly more harmful than bugs.

4 Likes
2

Reporting wise it’s pretty clear cut, if it’s a bug it belongs on the bug tracker over at projects.blender.org, the tracker has a pretty narrow definition of what constitutes a bug, essentially if it works as designed even if the design is sub optimal it is not a bug [1].

If it is classified as not a bug but you still like to see the behavior changed it is essentially seen as a feature request, which can be further explored on right click select [2]

[1] Reference/Not a bug - Blender Developer Wiki
[2] rightclickselect.com

3

Has there ever been a single case in the history of existence of Right Click Select, where not a big new feature, but a small UX issue (in a sense of a flaw in existing functionality, not addition of new functionality) was addressed based on a report from Right Click Select?

In fact, I challenge you to find a single Right Click Select entry proposing fix of a small usability flaw of this type, not a request for extending functionality of existing tool or adding a new feature/functionality.

4

That really doesn’t change the answer though, you asked where things should be reported, these are the places. If you feel your needs are being met on RCS or not is a very very different discussion.

5

Here’s my problem:

Both here, and on the bug tracker, the developers and triagers like to close reports and threads, claiming that the report or the thread was a feature request, and then, more often than not point the users to Right Click Select.

Most of them are quite familiar with the fact that RCS is not a place where reports of usability flaws of existing features would thrive. Most of them are also probably aware of the fact that developers rarely visit the site, and in the case they do, they probably never look for proposals to fix UX flaws of existing features, for two simple reasons:

  1. On RCS, these reports would get drowned in the noise, and shadowed by huge new feature proposals like “Add whole new simulation system to blender”.
  2. Due to 1, such reports almost never appear on RCS, since most users spot that problem immediately.

So we are in a paradoxical situation where developers and triagers suggest to users they should put their feedback onto a website they know is not suitable for that feedback and they know they don’t go to to gather feedback of that type.

This means that the developers and triagers are knowingly coercing users into performing a useless task and wasting their time. That is just bad faith.

The problem isn’t that much that the developers don’t care about usability issues (although they should, because it wasn’t the new features or the bug fixes which made Blender take off in popularity during the 2.8 boom, it was from the major part usability improvements), the problem is that they pretend they do.

It’s fine to say “We are not interested in feedback about UX issues.”, it’s just not fine to point users to take their time to write down that feedback in a place the developers are pretty much certain they will look for that kind of feedback.

6

That’s just a really long version of “I feel RCS isn’t meeting my needs” just because you feel that way can’t mean we ought to allow these things being reported in other places “Oh you’re unhappy with RCS? well that changes everything! go right ahead on the tracker/devtalk/chat then! our bad!” will not be the solution here.

1 Like
7

It’s not a feeling. It’s not subjective. It can be objectively proven that the cases where UX flaw was fixed based on content from RCS are little to non existent.

It’s not about RCS not meeting my needs. It’s not about just me. It’s about developers intentionally advising users spend time generating reports for certain type of feedback on a website they are very well aware they will never go to look for that type of feedback on.

Just telling someone you are not interested in feedback is one thing, but this is something akin of creating a report submission form where the reports get immediately deleted after submitting, without the user of the form knowing it.

This is no longer matter of something not meeting someone’s needs. This crosses the line over to the territory of unnecessary malevolence.

I am not saying the solution should be to allow users posting things that are not bug reports onto bug tracker. I am saying the solution should be to stop suggesting users use Right Click Select for the type of feedback that doesn’t make sense to be on RCS. To simply admit you have no official channels to report UX issues and you don’t intend to have any.

8

You are going off a bit on a tangent there, your question was “where do I report things” and I’m happy direct you to the resources currently available but not anything beyond that. The resources may not be as effective as you want, but it’s what we currently have and all I can point you to.

9

I don’t understand.

I didn’t ask where do I report things. I’ve specifically asked where do I report UX problems. As in a specific class of issues which don’t quality as bugs but not as new feature requests either.

Your response was that if it’s not a bug, but a something that I would like to see the behavior change of, you pointed me to RCS, despite you knowing that RCS is a place the developers would never go seek UX issues to fix.

My response for that was to point out it’s not appropriate to suggest RCS for this class of issues.

By saying “not as effective as I want” you are understating quite a bit. Almost certainly ineffective would be a better formulation. And at that point, why would you propose someone to do something that’s almost certainly ineffective?

So I think it wasn’t that much of a tangent here, but now I am going to go on one:

The reason this bothers me is that it’s very similar to what large corporations do when they pretend to have some technical support, but that entire technical support process is intentionally designed to discourage people from using it and make them leave. They simply do not want to spend resources on it.

Being told to use RCS feels exactly like that, an insult to injury. When you are writing it, you know it’s pointless, when I am reading it, I know it’s pointless. We both know it yet we are expected to pretend like we don’t. Blender is a open source project, so I don’t think this pretending is necessary. When it comes to rejecting specifically UX issue reports, a bit of honesty instead would go a long way, instead of directing people to a “fake report form” by the means of RCS.

10

as I explained in my first response, the way things are classified, it’s either a bug or a feature request, now you may disagree with that, you may have opinions on the effectiveness of RCS, but in the end these are your options. You made it very clear you don’t like them and I know you’d very much like to passionately debate about this for many more days to come. But that doesn’t change the options available to you, so I would very much like to opt out of that opportunity.

To summarize:

  • Bugs go on the tracker.
  • Any other changes in behavior are considered feature requests and should go on RCS.
  • You are very unhappy about that.
1 Like
11

Yes, this I will just never understand. If you, despite this entire conversation, once again suggest that UX issue reports should go RCS, even though you know they will never be utilized there, then I just can’t interpret it in any other way than bad faith.

All that would take to change it is to simply say:

  • Bugs go on the tracker.
  • Feature requests should go on RCS.
  • We don’t have any place to report UX issues.

But the way you are formulating it right now is intentionally leading people into wasting their time.

12

You may interpret in any way you like i certainly won’t be able to change your mind, given we mostly agree here, it seems like a great time to end this.

13