At what point does a UI entry for better UX become a feature?

[Draise14]

According to a conversation in #2230, there brings up the idea that some UI entries to improve UX (user experience) to make the job more artists friendly can be considered a "feature", meaning it can't be done nor maintained with Bforartists... so either it has to become an addon, or a feature request for Blender (which is practically nearly impossible to have implemented in the short term unless you do the code yourself for them - and even then, you have to go through revision and fit with the Blender vision, which ultimately is inconsistent and lacks iconography and the key UI entries/mods of Bforaritsts)

Sure, but this is a completely new feature, not a UI improvement :)

And yes, currently addons can just append or prepend to menus and panels. Or you make your own panels instead.

I think I may need to clarify to know when to filter proposals and feature requests and when to think about.... going to the Blender devs.

So first things first, definitions:

Definitions

UI = User Interface: the actual GUI, or buttons, sliders, panels, toolbars and shelves, editors, menus, sub menus, dropdowns, floating menus, widgets, viewports, etc.
UX = User Experience: the steps and processes you have to take to do particular tasks for a job.
Feature = An additional tool for the User: an operator or tool that can be used for a particular task to get the job done
Job = An artistic goal/result split up into steps that can be carried out with a sequence of tasks (UX) done with the tools (features) exposed in the UI.

Example: to do a job, the artists needs to use features through a UX. To use the features there is a certain UX. The UX is defined by how the UI is organized and exposed as a GUI.

If there is a bad UI, the UX is bad. If the UX is bad, the Feature is ultimately bad, and the artists won't be able to do the Job without a lot of effort.

Goals

Just to clarify, the goal of Bforartists is to improve UI - which is to ultimately improve UX, but for some UX you need better accessibility to quicker/easier workflows with added or more accesible/less beurocratic "routes" in the UI. On top of that, the GUI must be documented.

1. UI organization, development, iconography, exposure, cleanup of redundency, documentation and streamlining is supported
2. UX is then inherently improved by making life easier, quicker to pickup, faster to learn, and sometimes more direct to do small tasks.

But Feature development are out of the question, as that is Blenders developers responsibility. So we should avoid new features (ei, new tools) at all costs because to maintain them means lot's of code conflict, more labour on a merge, and/or maintaining addons.

There is some exception: some addons and features are included by default if they add to the UI and UX of Bforartists together, including resetting the viewport, rotating UV's by 90°, etc.

The key question:

At what point does a UI feature request (say an entry to a better UX with a new/optimized method of doing things) that ultimately improves the artists life to do his job become a whole new feature?

Secondary Questions:

• If their is no new API, it wouldn't change the core architecture - would it be ok to add better UX with new UI entries? So far, no new API is included with Bforartists, unless it's a new operator for Bforartists goals, editor or addon custom operators. (eg. The toolbar, the new view menus in the outliner, editor switchers, UI visibility toggles to hide content, tooltips modifications, etc) If a UX improvement used current API, and just adds code to make the bureaucracy simpler, would it be classified as a feature or an improvement with BFA?
• If it's a new operator class included in core documents, like a workaround to get to another operator or sequence of operators to work in sequence in a more efficient way for better UX, is it considered UI or Feature? Eg. The ability to do a certain task being brought up a few levels and streamlined as a new pie menu, or new brush optimizations, or a node editor ease of use feature like a node wrangler features.
• If the code for any new operator that uses the current API, it's UI entry and the UX improvement do not conflict and are kept in separate documents or tagged code in core documents - is it that much harder to maintain? Even if still classified as a UI or UX improvement, being new code with new operators - does that make it a feature?
• What does a Bforartists UX addon need to do be included, maintained and distributed with Bforartists?
• And at what point is UX features allowed to be included with Bforartists?
• Also, if there is more room to grow better UX with new operators and UI entries - how would the best least invasive method of coding it work for easy merges? Eg. Document of UX features for the relevant editor, called into the editor *.py document of the UI - like a baked in Addon similar to the toolbar?

Where does the line that defines what is a new feature and what is a UX improvement lie?

Reasons for the debate

• As Bforartists matures, the workflow deviates from Blender UX, especially the more refined the UI becomes - meaning there is room for better UX features. What is sustainable development for better UX?
• Bforartists will reach a point where the UI is mature enough (as it already is starting to be, just doing maintenance with Blender updates) - what will now make it stick out and be self sustainable/attractive to other artists and developers to still be self sustainable?
• At what point can new UX/features code be implemented and shared to the Bforartists community to the benefit of the competition of the locked Blender development? Ei, Official addon development guidlines?
• And also, what could be the method in the code to keep UX improvements clean and organized and merge conflict free from the Blender feature development to future proof the labour of staying up to date with Blender?

[ReinerBforartists]

According to a conversation in #2230, there brings up the idea that some UI entries to improve UX (user experience) to make the job more artists friendly can be considered a "feature", meaning it can't be done nor maintained with Bforartists...

Um. No. New features are welcome in general. This just means i need to think twice if i really want to have it in the code base and to maintain it. Because i am the responsible developer then to keep it working over the years. And i already spread super thin, and run at 250% at 24 hours and 7 days a week. I need a live from time to time ;)

Also to think twice is if a new request is really the solution, or if it introduces even more problems. And if there is not an even better way. I love this quote from Henry Ford. "If i would ask people what they want, then they would say faster horses"

When a new feature can be done by an addon, then that's to prefer. Since you can turn off addon when a future update breaks it. The same is not as easy when code in the core breaks ...

That for a first general statement. I will try to answer to the other points tomorrow :)

[ReinerBforartists]

On with the answer. The initial question is easily answered. A feature requires new code and brings new functionality. A UI fix usually works with existing code elements and does not add new functionality.

For me the core of your question is, why does Bforartists not become your inhouse tool, and fulfills all your needs and requests?

To answer that, first let's have a look at our current situation. The volunteer work of you and Iyad is highly welcome. Your work at the marketing front with Facebook and Discord is not forgotten, and as valuable as the work at the code base. And i am happy about every little bit. But when it comes to the vital part, the code, then that's still a drop in the ocean.

We have just one core developer. Me. And this includes everything. Webpage, documentation, code, graphics, marketing, support, learning videos and so on. And i spread super thin already. The non code things are eating me up. And the code things are killing me since i work in areas where i never wanted to work really. The weekly merge keeps me busy for three or four days a week already. One day merging, two or three days updating the manual. Remains roughly three or four days a week where i can do all of the other things, including having a life and a break here and there, and a weekend for myself. Okay, scratch the last part. Weekend is merging. But you see the problem with feature requests? When should i develop them? The day has just 24 hours. Features is best done by Blender. That way also more people benefits from it.

I have still fun with the project. But i have reached the border of what is possible already. I definitely will burn out with even more workload. We even slowly reach the point where even keeping Bforartists up to date comes to its borders. Blender evolves super fast at the moment. I had weeks already where i was just busy with merging and manual updates. And there is no end in sight. The new node editors are coming.

I would need more manpower. But i have nobody where i could delegate the work to. And so i have to set priorities and to decide what is possible and manageable. And this is why i want to focus at the UI. Not that feature requests are not welcome. But we don't really have the manpower for it. Better do one thing right than a dozen things half arsed. And that's the UI. There is still a ton of UI things left. And new features also needs to be documented and updated. New features also tends to be killed with a merge here and there. So as few new features as possible please.

I hope it is now clearer why i am not this happy about feature requests in general :)

That all said, you can make of course feature requests too, they are welcome. But there is not guaranteed that they will be included. It must be manageable and it must fit into the Bforartists philosophy. And the culprit is always if somebody finds the time to develop the feature, even when i agree.

So when you have a feature request, please first ask the Blender developers. The second best option is to write an addon. When it comes from our team, then i will include it into BFA. And the third best option is to write it in the native code. This is when everything else fails, and the feature is really a killer.

But in all cases, first let's talk if a new feature even makes sense and if we can manage it. That's the vital part.

I know that this process is a bit time consuming. It may need weeks or even months when i am personally unsure. And i have my own list of priorities. But please have the patience. There is a good reason for it. I don't want to lead the discussion if a feature makes sense while i decline the pull request for it. This is the highest possible frustration for both sides then.

One last general note. A feature is not accepted as long as a feature request has no task label assigned. And it is not declined as long as it is not closed.

[Draise14]

Thanks for clarifying. Yeah... makes sense, there is a lot of work so best to keep it focused. Hopefully in the future these other tasks with these extra things can ease up the pressure and others can do these tasks over time.